Deploy an app
Choose a deploy method
| Method | What it does | When to use |
|---|---|---|
| kamal | Conductor runs Kamal as the control machine (in its own container): clones your repo, builds on the target's docker daemon over SSH, and deploys. You keep kamal logs / kamal console. |
Containerized apps you want on Kamal. |
| native | Git-based release over SSH on the box (Puma + systemd). | Hatchbox-style native Rails apps. |
| docker | Build + run a container directly. | Simple container apps. |
Set the method on the app (UI Edit app, or the conductor_app update action).
What a deploy does
Triggering a deploy (the Deploy button, or conductor_app deploy) creates a Deployment and dispatches by method:
- Clone / sync the repo to the target commit (using your GitHub connection for private repos).
- Build the release (Kamal builds on the target's daemon over SSH — no docker socket mounted into Conductor).
- Release + health-check, then mark the deployment succeeded or failed.
A deploy preflight runs first — it blocks on an at-risk server audit, a deploy hold, or a failed seed run (pass force: true to override), and Kamal deploys run gated migrations (db:migrate + abort_if_pending, fail-loud).
Environment variables
Set per-app env in Conductor (UI, or conductor_app_config set_env). For kamal apps, Conductor generates .kamal/secrets from these at deploy time — so the UI is the source of truth for SECRET_KEY_BASE, DATABASE_URL, etc.
Status & rollback
conductor_read fleet_status shows each app as running / stopped. Kamal retains prior image versions — roll back with conductor_app rollback (boots a prior release, no rebuild).