Trigger — manual, deliberate
→ Platform Settings
Only the Owner turns the mode on — with a toggle in the platform
settings, with confirmation. The state is
platform_settings.maintenance_mode
(boolean, singleton). It is not part of the deploy:
a rolling backend update proceeds without downtime. The toggle is for
rare work with deliberate downtime (a heavy DB migration,
an incompatible schema change); when it is on, sync
and agents are paused.
For users — a full-screen stub
→ System Screens
When the flag is on, the backend responds
HTTP 503 with
Retry-After (the unavailability is temporary, not “page
removed”), and the frontend renders the full-screen
maintenance stub. A full screen was chosen, not read-only.
Administrator access bypassing the mode
Owner and Admin keep access while the mode is on — otherwise the
operator would lock themselves out and couldn't check the platform before
lifting it. They are not served
503; ordinary
users see the stub.
Hard mode — at the proxy levelv2
The toggle above works while the application is alive. If the
backend itself is down (a restart, a container update), the flag is unavailable
along with it — a static stub is then served by the reverse proxy
(Nginx). This is a separate “hard” mode at the
infrastructure level; it is not implemented in the first iteration.