Via

Deploy diagnostics

When a deploy reaches a terminal failure, stay on first-party commands:

vary app status my-api --target prod
vary app inspect my-api --target prod
vary app logs my-api --target prod --source build --tail 200
vary app smoke my-api --target prod
vary app debug-bundle my-api --target prod
vary target doctor --target prod

status includes the latest deploy id, build id, failure phase, failure reason, and next commands. Runtime capability readiness failures include a structured failed-capability block with the capability id/type, bound resource, binding name, expected condition, observed state, failing check, and next command.

logs never returns empty output ambiguously: when a stream has no entries it prints No <stream> log entries found for <object>; try <next command>. Use --quiet-empty only for scripts that intentionally accept an empty stream.

smoke checks the externally advertised route from the workstation. If the app only has an internal or pending route, it reports that state instead of presenting the internal route as a public URL.

debug-bundle writes a redacted zip containing status JSON, inspect JSON, deploy/build details, selected logs, target doctor/status data, toolchain data, and version metadata.

Route readiness in status --json is layered. Each route can report domain_verification, certificate, load_balancer, runtime, readiness, blocking, owner, and remediation. If the route table and domain/certificate state disagree, the diagnostic is state_inconsistent and the route readiness is blocked_state_inconsistent; use the remediation command and operator route/domain tools instead of editing proxy or database state.

App status

vary app status my-api --target prod

The status command reads from the control plane and prints:

Field groupIncluded data
App identityApp name and server URL
Current deployCurrent deploy id and state
Latest deployLatest deploy id and state
SourceCommit and ref
ArtifactArtifact hash
Build/runtime metadataToolchain and runtime image
Runtime instanceContainer id and runtime state
ExplainerOne-line summary at the bottom

Healthy output ends with:

=> running - container up and serving traffic.

If the latest deploy failed while an older one is still serving, status prints two blocks: the current healthy deploy and the latest failed deploy. In that case the command exits non-zero and the explainer ends with:

=> deploy failed ...

Logs and retries

vary app status my-api --target prod
vary app doctor my-api --target prod
vary app repair my-api --target prod
vary app logs my-api --target prod --source build --tail 200
vary app build <build-id> --target prod
vary app build logs <build-id> --target prod --app my-api --follow
vary app build cancel <build-id> --target prod --app my-api --follow
vary app deploy retry <deploy-id> --target prod --app my-api --apply-manifest --follow
vary app deploy <deploy-id> --target prod

For failed deploys, start with status: it prints the latest deploy/build identifiers, route health, runtime health, dependency failures, and the failed phase/reason. If smoke reports runtime_identity_expired, run doctor, then repair; the repair path renews runtime identity by replacing or relaunching the workload instead of reporting a no-op restart.

logs --source build returns the persisted build log, including redacted stdout/stderr from the failing phase. Use build <build-id> for phase status, heartbeat, worker id, log availability, and next commands. Stuck builds can be cancelled with vary app build cancel <id> --target prod --app my-api --follow, then retried with vary app deploy retry <deploy-id> --target prod --app my-api --apply-manifest --follow. Use deploy <deploy-id> for source ref, commit, build/artifact ids, events, and terminal state.

App-owner command surface

The full vary app command list is in Via CLI reference; the workflow groupings are:

GroupCommandsWhat they do
Lifecyclevary app deploy, vary app rollback, vary app restart, vary app stopShip new releases, roll back to prior releases, and control the current runtime.
Status and historyvary app status, vary app inspect, vary app builds, vary app build, vary app releasesInspect deploy and build state; most read commands support --json.
Logs and diagnosticsvary app logs, vary app smoke, vary app doctor, vary app preflight, vary app debug-bundleRead persisted build/runtime logs, exercise the public route from the workstation, diagnose runtime/build incidents, run readiness preflight, and write a redacted support bundle.
Repairvary app repair, vary app restart, vary app build cancel, vary app deploy retryRenew runtime identity, restart unhealthy workloads, cancel stuck builds, and retry failed or cancelled deploys without direct state edits.
Config and envvary app config template/apply/patch/validate/diff/redeploy, vary app env set/rotate/historyGenerate config templates, apply redacted secrets, stage immutable config profile versions, and rotate secret-backed env without a new Git push.
Sourcevary app source show/resolve-ref/commits/remote/refsInspect the Via-hosted Git source surface.
Manifest and platformvary app manifest apply, vary app domain list/request/verify, vary app route addApply declarative manifest state and manage app-owned domain and route requests.

Cleanup decision tree

Use cleanup commands based on what should remain true after the action:

SituationFirst command
Stale route or add-on statevary app reconcile my-api --target prod --apply-manifest --plan --json
Failed or cancelled deploy is ready to retryvary app deploy retry <deploy-id> --target prod --app my-api --apply-manifest --follow
Temporary runtime stopvary app stop my-api --target prod
App identity is retired or unrecoverablevary app delete my-api --target prod --plan --json

Do not use delete for routine deploy retries. Delete/decommission requires a read-only plan first, then --apply --confirm <app>. It disables route/runtime exposure before stateful cleanup, retains add-ons by default, and reports retained resources, tombstone/name-reuse state, and audit event IDs. If the developer command is blocked by policy, attach the plan output to an operator escalation and have the operator run via app delete <app> --plan --json on the host.

If decommissioning fails after cleanup has started, the result code is delete_partial_retryable, partial is true, and the app state is decommission_failed. Fix the named blocker and run the returned retry_command.

Operator commands are covered by Domains and routes and Operations.

← Deploy lifecycle
Config redeploys →