Deploy command#

Usage:
  zyn deploy [--no-input] [--maintenance] [--skip-tests] [--timings]

Options:
  --maintenance  take HTTP and workers offline before applying migrations

Test, build, and activate the application on the configured production host.

Example:
  zyn deploy

Documentation: zyn docs cli/deploy

zyn deploy ships the current application to its configured Linux host. The first run asks for the host and an optional domain; a domain enables automatic TLS, while an empty domain continues to the HTTP port prompt. It writes deploy.zon, prepares the production credential profile, and continues the deployment. Later runs reuse that configuration. Deployment reads the existing zyn.zon without adding scaffold defaults. Host, domain, and port prompts share the cursor and word-editing controls used by the zyn init name prompt.

Production credential preparation permits absent .optional_private fields. Empty values saved in the credential editor are treated as absent. Missing required credentials are reported by their dotted schema paths, without values, before opening the editor and again if they remain missing after editing.

Unless --skip-tests is supplied, deployment first runs the same application suite as zyn test. It then checks the host, builds the application for the detected architecture, uploads it, and activates the release. Registered background jobs receive a slot-matched production worker. Deployment validates queued names and arguments without mutating recurring schedule state before stopping the previous worker, repeats that validation after the old HTTP release drains, and starts the candidate worker only after HTTP cutover. The activated worker synchronizes its recurring source definitions before readiness; rollback restores the previous worker and its source-authoritative schedules. The URL uses the first configured domain when present; host-only HTTP deployments retain a configured non-default port.

After application activation, deployment provisions production access and saves its verified endpoint and public host key in deploy.zon.access_endpoint. Commit this metadata so approved agents can verify the server. Access readiness is reported separately: an access failure warns without rolling back the release. See Deployment for private OpenSSH over Tailscale, optional endpoint configuration, and existing-install upgrades.

--maintenance selects a deployment with downtime instead of overlapping HTTP releases. Tests, the build, and upload finish before maintenance begins. Zyn closes public application traffic, drains and stops HTTP services and job workers, then applies migrations. Traffic reopens after the candidate and its worker are ready. Once maintenance begins, a failed or interrupted deployment remains in maintenance rather than restarting potentially incompatible old code. Correct the failure and rerun zyn deploy --maintenance; an ordinary deployment refuses to leave that state. Database changes are not automatically reversed. The flag can be combined with --skip-tests and --timings in any order. Maintenance does not bypass healthchecks or queued-job compatibility checks. Upgrading framework job schema revision 9 or 10 to 11 when a previous worker exists requires --maintenance; an ordinary deployment rejects the upgrade before running migrations.

Interactive output shows live deployment status. An active release upload shows its percentage, transferred and total bytes, transfer rate, and labeled ETA. After completion, the row retains its total size and average rate beside the phase duration. Redirected output omits animation and progress meters. A failed subprocess prints a bounded diagnostic tail; healthcheck failures include the probe result and relevant service diagnostics.

--timings adds the build timing report and Zig build-step summary described in cli/build. It may be combined with the other deployment flags. It does not change the deployment target or disable tests.

After interactive configuration and credential prompts finish, terminal input is ignored and discarded until deployment completes.

See zyn docs framework/deployment for configuration, server requirements, credentials, healthchecks, blue/green activation, connection draining, rollback, and maintenance constraints. --no-input requires an existing deploy.zon; a missing file fails with instructions to create it or run initial setup interactively. Deployment SSH then uses batch authentication and strict existing host-key verification with a ten-second connection timeout. Provision a verified known_hosts entry and non-interactive key authentication before retrying. This option never approves an unknown SSH host key, requests a password, or enables maintenance implicitly.