stado service deploy
Invocation
stado service deploy [OPTIONS] <NAME>Purpose
Install a new unit under management: render, push, bootstrap, record
Required inputs and options
| Input or option | Contract |
|---|---|
<NAME> | Service name; lowercase letters, digits, '.', '-' and '_' |
--host <HOST> | Explicit registry host to install it on |
--host-heuristic <HOST_HEURISTIC> | Declarative placement selector resolved against the registry |
--from <FROM> | Absolute path, ON THE TARGET HOST, of the program the unit runs. The plist / systemd unit is rendered around it by the same renderer `stado bootstrap --local` uses |
--from-artifact <FROM_ARTIFACT> | Published artifact to install and run instead of a path already on the host. The reference is resolved to an immutable version, that version is placed under ~/.stado/services/NAME/<version>/, its declared sha256 is verified there, and `current` is moved onto it. The unit runs through `current`, so a later install or a rollback is a relink rather than a redeploy |
--arg <ARGS> | One argument the unit is started with; repeat for each. A program that needs a subcommand or a port to be the service it is named after cannot be deployed without these, and hand-starting it beside the unit is how a host ends up serving on a port no declaration mentions |
--launchd-label <LAUNCHD_LABEL> | Keep this exact launchd label instead of minting one from NAME. Darwin only; used when a managed daemon is recreated as a per-login LaunchAgent without changing its service identity |
--as-launch-agent | Install a Darwin service as a per-login LaunchAgent even when the target is declared always-on. The host must have a live gui/<uid> domain; deployment refuses instead of falling back to a daemon |
--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
- A program that needs a subcommand or a port to be the service it is named after cannot be deployed without these, and hand-starting it beside the unit is how a host ends up serving on a port no declaration mentions
- The host must have a live gui/<uid> domain; deployment refuses instead of falling back to a daemon
- 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.