stado service update
Invocation
stado service update [OPTIONS] --host <HOST> <NAME>Purpose
Move an already-managed service onto a new artifact version. `deploy` installs a unit that is not yet managed and refuses to touch one that is. This is the other half: the unit is left exactly as it is, the new version is placed beside the running one and `current` is relinked, so the change takes effect on the next restart and a rollback is a relink rather than a redeploy.
Required inputs and options
| Input or option | Contract |
|---|---|
<NAME> | Service name as the registry manages it |
--host <HOST> | Command option; required or optional as shown in the invocation. |
--from-artifact <FROM_ARTIFACT> | Published artifact to install |
--from-archive <FROM_ARCHIVE> | Local release archive to install, for a bundle that no object store the fleet shares is carrying yet |
--rollback-to <ROLLBACK_TO> | Point `current` back at a version directory already on the host |
--refresh-image | Reconcile and verify the live kernel image after installation |
--json | Command option; required or optional as shown in the invocation. |
Output and state effect
It performs the operation described above and emits its operator result on standard output or standard error. Any state change is limited to the resources and records named by the purpose and options on this page.
Refusals
- Before dispatch, Stado refuses a missing required token shown in the invocation, an unknown option, or a value outside a listed value set; argument-usage failures exit with code 2.