Increases the `/features` endpoint polling interval (runtime config
polling) from the current 30 seconds to 10 minutes.
## Background
The polling was originally added for two main purposes:
1. Server alert badges
2. Extra assurance that states are synchronized between frontend and
backend
However, both of these use cases are not critical:
- Server alert badges are unlikely to be needed in practice. WebSocket
(WS) can be used eventually as an alternative
- For synchronization, the system should be redesigned to be explicit
about marking client state as stale, or use WebSocket/Server-Sent Events
(WS/SSE) on a per-data basis rather than polling for the entire feature
flag set
## Motivation
The reason to reduce polling frequency is that per-user feature flags
are being added, which will make `/features` endpoint handling
significantly heavier. The endpoint will no longer just return static
JSON with high cache age, making frequent polling more costly.
## Future Considerations
- Eventually migrate server alert badges to use WebSocket
- Design a system that explicitly marks client state as stale when
needed
- Consider using WebSocket or Server-Sent Events for targeted data
updates instead of polling entire feature flag set
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7100-cloud-increase-feature-flag-polling-interval-to-10min-from-30s-2bd6d73d365081dfa8abeec901d0d975)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Alexander Brown <drjkl@comfy.org>
## Summary
Implements server-side remote configuration to decouple runtime behavior
from build artifacts, enabling dynamic configuration updates without
redeployment.
## Technical Changes
- **Replaced** build-time constants (`__MIXPANEL_TOKEN__`,
`__BUILD_FLAGS__`) with runtime configuration loaded from
`/api/features`
- Configuration now sourced from `window.__CONFIG__` (hydrated from
`/api/features` endpoint)
- **Added** `src/platform/remoteConfig/` service that polls server
configuration every 30 seconds
- **Modified** application bootstrap sequence in `main.ts` to load
remote config before module initialization (required for cloud builds)
- **Removed** global constants: `__BUILD_FLAGS__`, `__MIXPANEL_TOKEN__`.
Runtime subscription enforcement toggle via `subscription_required` flag
- Server health alerts with variant-based severity rendering
(info/warning/error) via topbar badges
## Rationale
- **Build-once-deploy-anywhere**: Single immutable artifact promoted
through environments (staging → production)
- **Zero-downtime configuration**: Update behavior without rebuilding or
redeploying the application
- **Incident response**: Disable features or display alerts dynamically
in response to outages or degraded service
- **Instant rollback**: Revert configuration changes server-side without
artifact redeployment
- **Progressive delivery**: Enable A/B testing, canary releases, and
user/region-based configuration
- **Environment parity**: Eliminate configuration drift between staging
and production builds
- Decouples deployment cadence from configuration changes
- Enables GitOps workflows for configuration management separate from
code deployments
- Supports real-time operational control of client behavior
- Reduces build matrix complexity (no per-environment builds)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6246-change-cloud-feature-flags-to-be-loaded-dynamically-at-runtime-rather-than-set-in-build-2966d73d3650811cbb41c9093961037a)
by [Unito](https://www.unito.io)
