You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 0500adf
Browse filesBrowse the repository at this point in the historyBrowse files
During platform upgrades and rollbacks, administrators can now follow
saved lifecycle progress at `/admin/status`. The authenticated page
shows source and target versions, phase, timestamps, and the API's
independently observed traffic state. It refreshes while visible,
preserves the last confirmed snapshot when updates fail, and prompts for
sign-in when the session expires.
The CLI previews availability impact, saves resumable progress, and
prints concrete recovery commands that retain custom runtime paths.
`platform status <installation-id>` shows the local checkpoint before
live discovery. Visitors receive a temporary-unavailability page with a
manual retry link; API and mutation requests retain HTTP 503 responses
without automatic replay.
Existing traffic guards, administrator authentication, Sandbox drain
access, and runtime-only rollback behavior remain in place. Completed
operations on disabled installations still report paused traffic. The
status page requires a reachable API and authentication database; these
changes do not guarantee zero downtime.
Documentation and regression coverage cover these workflows. The
missing-package resolver regression also runs in native Node so the test
runner's workspace resolution cannot mask an uninstalled package.
Validation:
- Core and packaged runtime builds, package typechecking, lint, and
formatting passed.
- Mobile browser coverage verified stale snapshots, refreshed progress,
paused traffic after completion, and no horizontal overflow.
- Full suite after syncing with main: 673 files passed, 1 skipped;
12,717 tests passed, 31 skipped.
- Live Cloudflare deployment tests remained gated by absent E2E
credentials.
Copy file name to clipboardExpand all lines: docs/guide/platform/administration/operations.md
+11Lines changed: 11 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -66,6 +66,17 @@ The dashboard’s **System Status** page refreshes health checks every 30 second
66
66
67
67
Use `void platform upgrade`, `repair`, `disable`, and `enable` to maintain your platform. See [platform maintenance](/guide/platform/installation/maintenance#resume-repair-recover-and-upgrade).
68
68
69
+
Upgrades and rollbacks run through the CLI; watching their progress is optional.
70
+
During maintenance, navigating the admin UI automatically redirects to
71
+
`/admin/status`. You can also open that page directly on the API origin. It
72
+
refreshes automatically and shows saved progress and the API's traffic state
73
+
while the API and authentication database remain reachable. If a status refresh
74
+
fails, the last confirmed snapshot is marked as stale. Normal administrator
75
+
changes stay paused during maintenance.
76
+
If the CLI reports an error or a waiting state, follow its recovery instructions
77
+
to resume the operation. See
78
+
[Follow upgrade and rollback progress](/guide/platform/installation/maintenance#follow-upgrade-and-rollback-progress).
79
+
69
80
For disaster recovery, keep a matching PostgreSQL backup, provider data backups, installation identity and complete project-encryption keyring, and immutable runtime artifacts. Keep traffic disabled while restoring data, run `discover` to reconstruct verified local metadata, and review `repair --plan` before recreating missing installer-owned infrastructure. Neither command restores backed-up data. See [Prepare for disaster recovery](/guide/platform/installation/maintenance#prepare-for-disaster-recovery) for the full sequence.
Copy file name to clipboardExpand all lines: docs/reference/cli/platform.md
+5Lines changed: 5 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,6 +16,11 @@ void platform status [id]
16
16
17
17
`use` and `status` auto-select the only configured platform; with multiple platforms they show a picker interactively and require an id or URL in non-interactive use. A project with a recorded platform URL keeps using that platform when the global default changes.
18
18
19
+
For a self-hosted installation, `status <installation-id>` prints locally saved
20
+
lifecycle progress before checking the live API. The saved checkpoint may be out
21
+
of date. If live discovery fails during maintenance, the command still shows that
22
+
checkpoint and exits with an error; it does not confirm current availability.
23
+
19
24
## Operator commands {#operator-commands}
20
25
21
26
Use `void platform` to administer the users and apps on your selected platform. Start with the [Platform Administration guide](../../guide/platform-administration.md) for signing in, giving people access, and investigating deployments.
Copy file name to clipboardExpand all lines: packages/void/AGENTS.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -67,6 +67,8 @@ generated entries must preserve the module-boundary rules below.
67
67
68
68
### Key Design Decisions
69
69
70
+
-**Lifecycle progress**: Save operation phases under the installer database lock. Resume an operation ID only for the same action and target runtime digest. Progress describes the saved operation, not project availability; preserve traffic guards and report disabled installations separately from completed upgrades or rollbacks.
71
+
70
72
-**Platform resource identity**: New installations use `void-<installation-name>-<role>` names, without random suffixes. Conflicts fail closed; only matching ownership records/markers authorize reuse or resume. Externally managed Hyperdrive is an exception: users select it by ID, its name may differ from the generated name, and the selected name and origin are pinned for recovery. Keep recorded names and recovery behavior for older suffixed installations, and keep installation IDs/ownership nonces in metadata. Do not change application/user naming when changing platform infrastructure naming.
71
73
72
74
-**Platform test origins**: Domain installations remain the default recommendation. Explicit `platform install --workers-dev` uses schema-v2 application routing and a forwarding Worker per project; normal domain platforms keep schema v1. `platform domain set` checkpoints pending DNS separately, verifies the live runtime token and HTTPS, then hands activation to the authenticated platform API. The service durably prepares Zero Trust destinations and project routing before publishing `PLATFORM_APPLICATION_KEY`; the CLI never publishes that key directly. API and dispatch resolve that configuration into a request-local environment copy. Preserve the original workers.dev identity and API origin. Forwarders share the main slug routing entry, validate its project ID, and honor suspension/disablement. They remain for manual cleanup, and their unpurgeable workers.dev edge-cache layer is bypassed while shared ISR remains enabled.
0 commit comments