Deploy updates

The Deploy page shows only what needs a person or is happening right now, in three groups:

• Needs your decision — plans waiting for approval, a test computer to check, a next wave to release, or failed computers to retry.
• Ready to deploy — released Blueprint versions that some computers do not have yet. Each card has one button, Deploy…, which asks whether to try one computer first (recommended) or send to everyone, and then prepares a plan for approval.
• Running — deployments Cybex is working through by itself.

When all three are empty the page says Nothing needs your attention. Finished, stopped, and rolled-back deployments move to Deployment history (the button at the top of the page, or /updates/history), where each one is a single row with its outcome, the failed computers behind Show failed computers, and Roll back… where a safe previous version exists. An older released version can also be restored from the Blueprint’s version ledger with Restore vN….

Save & Deploy in the Blueprint editor and Deploy… on this page both create an immutable Blueprint candidate and a preflight plan. Neither updates James, updates a computer, or changes the active Blueprint. Nothing starts until an administrator reviews and approves that exact plan.

Review the preflight

Before approval, Cybex shows:

• the Blueprint change and the computers in scope;
• the minimum James and workstation-runtime versions and capabilities the Blueprint needs;
• which components and computers will change, which compatible computers will remain untouched, and why;
• signed artifact and exact source identities;
• health and connectivity blockers; and
• any one-time action an administrator must take.

A healthy computer can keep its current Blueprint and runtime indefinitely. Cybex does not update it merely because a newer release exists.

Select Approve and start only after the plan matches your intent. If a prerequisite is incompatible or needs a reinstall, approval remains unavailable and the plan explains what to fix. Use Discard plan when the candidate or target set should be reviewed again.

Follow the release timeline

After approval, the page reports the exact active stage:

1. Waiting for approval — preflight is complete and nothing has changed.
2. Updating James — only James appliances missing a required capability receive their pinned signed update.
3. Updating workstation runtime — only affected computers receive the existing signed runtime rollout.
4. Verifying compatibility — Cybex checks fresh versions, capabilities, identity, and health.
5. Applying Blueprint — only verified ready computers receive the new Blueprint.
6. Completed — every completed target has reported the exact result.

The current Blueprint remains active during preparation, waiting, and failures. The page shows progress and a specific reason for each component and computer. In a test-first deployment, review the completed test computer and select Approve next wave before the remaining wave begins.

Custom wallpaper example

A custom wallpaper requires blueprint_wallpaper_v1. The preflight explains that James must be able to prepare the wallpaper and that affected workstations need a compatible Cybex Agent and apply helper. After approval, Cybex verifies or updates James first, updates only the workstations that need the compatible runtime, verifies their reports and health, transfers the pinned wallpaper, and then applies the Blueprint.

A computer still using a Blueprint without that wallpaper remains unchanged until it is a ready target in the approved plan. If preparation or transfer fails, its previous Blueprint and wallpaper stay active.

Offline and legacy computers

An offline computer is shown as Offline — waits safely. It receives no runtime or Blueprint command and keeps its current Blueprint. Ready computers can continue in their own waves. When the offline computer reconnects, select Check again and resume so Cybex rechecks its identity, version, capabilities, and health without repeating completed work.

Some older computers can enter the managed update path through a One-time bootstrap required step. The signed bootstrap preserves the current Blueprint while installing the compatible Agent, NixOS module, apply helper, and runtime updater. The existing runtime must report both apply_blueprint and restart_agent: applying the bootstrap and restarting into the signed successor are both mandatory. A computer that is too old to accept either part of that protected bootstrap is marked Reinstall required; reinstall it with the current Cybex installer before creating a new preflight. A legacy James appliance without the protected updater similarly requires the current signed James appliance media.

Failures, retries, and rollback

When a stage fails, later stages do not start. The page identifies the failed component or computer and whether administrator action is required.

• Retry failed stage retries the existing failed stage from its safe boundary. Completed component and computer work is not repeated.
• Check again and resume rechecks a paused or repairable blocked stage.
• Stop release plan prevents later stages from starting while safely settling work already dispatched.
• Roll back restores the persisted previous Blueprint on computers changed by this release. Computers that never reached Blueprint apply remain untouched.

Local James and workstation-runtime activation failures continue to use their existing protected rollback. Release progress and child-work links are stored durably, so a Management service restart resumes the same approved plan rather than creating duplicate updates.