diff --git a/docs/MIGRATION_VERIFIED.md b/docs/MIGRATION_VERIFIED.md deleted file mode 100644 index 66af90612..000000000 Binary files a/docs/MIGRATION_VERIFIED.md and /dev/null differ diff --git a/docs/features/atomic-deployments.mdx b/docs/features/atomic-deployments.mdx index 948d35645..a500aa744 100644 --- a/docs/features/atomic-deployments.mdx +++ b/docs/features/atomic-deployments.mdx @@ -67,7 +67,7 @@ Check this panel in the dossier before rolling back a stack that has been runnin The entry is also hidden for users who lack the `stack:deploy` permission. Ask an admin to grant `stack:deploy` through **Settings · Access** if the entry does not appear. - The health probe is a 3-second window after `docker compose up -d` returns. Crashes after that window are out of scope for atomic rollback, because Sencho cannot tell a late exit apart from a normal restart. The [health gate](/features/health-gated-updates) covers exactly this period: it observes the stack for a configurable window after the update, records a verdict on the stack timeline, and offers a manual rollback when containers do not stay healthy. The gate does not auto-compensate. For ongoing health beyond that, use [Auto-Heal Policies](/features/auto-heal-policies) to restart unhealthy containers automatically and [per-stack alert rules](/features/alerts-notifications#per-stack-alert-rules) to page you when a container exits unexpectedly. + The health probe is a 3-second window after `docker compose up -d` returns. Crashes after that window are out of scope for atomic rollback, because Sencho cannot tell a late exit apart from a normal restart. The [health gate](/features/health-gated-updates) covers exactly this period: it observes the stack for a configurable window after the update, records a verdict on the stack timeline, and offers a manual rollback when containers do not stay healthy. The gate does not auto-compensate. For ongoing health beyond that, use [Auto-Heal Policies](/features/auto-heal-policies) to restart unhealthy containers automatically and [per-stack alert rules](/features/alerts-notifications#stack-alert-rules) to page you when a container exits unexpectedly. This message means the auto-rollback attempted to restore from the recovery generation and re-deploy, but the restore step or the re-deploy itself errored out. The generation remains listed under **Resources → Rollback**. To recover: diff --git a/docs/features/cve-suppressions.mdx b/docs/features/cve-suppressions.mdx index ffebc4dff..720a12e81 100644 --- a/docs/features/cve-suppressions.mdx +++ b/docs/features/cve-suppressions.mdx @@ -139,7 +139,7 @@ You can also export the full set of triage decisions as an **OpenVEX** document - **Expired rule.** If **Expires in** was set, the suppression stops applying after the deadline. The panel shows an `expired` badge on that row; remove it and create a fresh rule. - Each replica anchors to the first control fingerprint it receives. If a different control later tries to push (for example, after rebuilding the control from a snapshot or migrating it to a new server), the replica rejects the push until it is reanchored. The reanchor procedure (admin API call on the replica) is documented in [Fleet Sync](/features/fleet-sync#control-anchor); the next push from any control after a reanchor becomes the new anchor. + Each replica anchors to the first control fingerprint it receives. If a different control later tries to push (for example, after rebuilding the control from a snapshot or migrating it to a new server), the replica rejects the push until it is reanchored. The reanchor procedure (admin API call on the replica) is documented in [Fleet Sync](/features/fleet-sync#anchor-and-re-anchor); the next push from any control after a reanchor becomes the new anchor. The fleet sync wire protocol caps a single push at 5,000 rows so a misconfigured control cannot wedge a replica with an unbounded payload. If your local list exceeds that cap, the warning appears in the control logs and only the first 5,000 rows are pushed. Trim expired or unused entries from the suppressions panel, or split scopes across distinct rules, so each remains meaningful before relying on fleet replication for the full set. diff --git a/docs/features/overview.mdx b/docs/features/overview.mdx index 5ebfb4b5f..c7aac7cf4 100644 --- a/docs/features/overview.mdx +++ b/docs/features/overview.mdx @@ -219,7 +219,7 @@ Open an interactive terminal on the host OS directly in the browser with full xt ## Security and access - The Security page: the 'Action needed' masthead with critical and high CVE counts and last scan time, the tab strip (Overview, Images, Compose risks, Secrets, Policies, Suppressions, History, Scanner setup), the actionable findings summary listing fixable CVEs, detected secrets, and exposed images, and the 30-day risk trend chart. + Sencho Security view with the posture masthead, action summary, review queue, risk trend chart, and the tab strip ### Security diff --git a/docs/features/resources.mdx b/docs/features/resources.mdx index 390859040..bb52212a0 100644 --- a/docs/features/resources.mdx +++ b/docs/features/resources.mdx @@ -147,6 +147,10 @@ The toolbar above the list provides a **Select all** checkbox and a destructive When no external containers are detected, the tab shows a success state with the message "No external containers" and the subline "All running containers are managed by Sencho." +### Rollback + +Lists the recovery generations the node is holding, with a search box, a **Current** or **Superseded** filter, and sortable columns. An admin can release a generation's protection early from a row. [Automatic rollback images](/features/health-gated-updates#automatic-rollback-images) explains what each generation holds, how long it is kept, and what releasing costs. + ## Troubleshooting diff --git a/docs/tutorials/configure-environment-guardrails.mdx b/docs/tutorials/configure-environment-guardrails.mdx index d04a70a52..031c51997 100644 --- a/docs/tutorials/configure-environment-guardrails.mdx +++ b/docs/tutorials/configure-environment-guardrails.mdx @@ -62,9 +62,6 @@ This tutorial covers one guardrail: **Block deploy on missing required env vars* Select **Save & Deploy** and this time keep **Save & Deploy** in the dropdown (not **Save Only**). The operation fails immediately, before any container changes, with **Deploy blocked: required environment variable DB_PASSWORD is missing. Define it in a .env or env_file, then deploy again.** The full message appears in the notification bell in the top bar. - - Notifications panel showing 'Deploy blocked: required environment variable DB_PASSWORD is missing. Define it in a .env or env_file, then deploy again.' from a Save & Deploy operation. - This demonstrates the fix: the guardrail message now properly appears when using **Save & Deploy**, matching the exact message shown when using **Update**. **Save & Pull Images** is covered by the same guardrail and refuses the same way, naming that action in the last sentence instead.