Installation and updates
Stage an exact release, hand off compatible services and retain a tested rollback path.
Install for the machine’s role
The terminal installer supports operator, controller and Linux incus-host roles. Run its plan first; dependency installation and provisioning are explicit apply actions. Select an exact published version and matching OS/architecture archive.
Releases are immutable. Configuration, API tokens, agent homes and private state stay outside release directories. Linux node helpers live under a root-owned prefix. The installer does not silently initialize disks or change unrelated host services.
See installation commands and service setup. Use the source quickstart when qualifying an unreleased revision.
Compatible updates keep a stable front door
- Stage and validate the exact archive and manifest.
- Start the candidate controller in standby behind the existing supervisor.
- Gate new mutations, drain admitted work and transfer exclusive state ownership.
- Switch routing after readiness succeeds; retain the previous compatible release.
The supervisor retains the API/dashboard listeners during the handoff. Native agents already running in independent VMs do not need a VM restart for a controller update. The supervisor itself, host kernel, Incus and drivers have separate maintenance lifecycles.
Rollback depends on state compatibility
Use enginebox-install to stage, update or roll back a release; the update guide gives the full version, artifact and token-file arguments. Do not replace a live binary or point a service at an arbitrary older directory.
Rolling back a controller does not restore databases, private homes or VM memory. Older storage binaries reject newer LayerFS workspace records, but older controllers may not understand attachment markers. Detach all LayerFS checkouts before a controller rollback outside the supported compatibility boundary.
The first Python-to-Rust deployment needs a brief control-plane cutover because the legacy controller lacks the drain and ownership protocol. Preserve its private state; subsequent compatible Rust releases use the supervised handoff.
Build checks and deployment are separate
The Rust port is merged. Native build/test checks cover Linux, macOS and Windows; isolated macOS/Linux archive staging and Rust-to-Rust update/rollback have been exercised. Existing hosts are not upgraded merely because a PR merged.
The reference fleet now runs Rust 0.3.1-live.0 with account state preserved, native helper/browser migration on two private workspaces, and native-dev revision 4 plus two fresh reserves synchronized. Fresh physical-host bootstrap, Windows service installation and independently reproduced installs remain release acceptance gates. Check current qualification before choosing a deployment target.