deploy

coolship deploy [target] [flags]

deploy submits one deployment of the linked application and, by default, waits for it to finish. It does not upload your worktree or push local commits; Coolify deploys from its configured source and branch. Deployments explains the model.

In a terminal, the deployment is a checklist: the target, then the deployment and its stages — build, rolling update, container, cleanup — ticking as Coolify's build log markers arrive, with a spinner and elapsed time on whatever is open. The build log stays collapsed at normal verbosity; it is printed in full if the deployment fails. With --verbose or --debug no checklist is drawn: the plain stage and status lines print instead, with each finished stage's duration and the time since the deployment was queued, and the build log streams unless --no-logs or the build_logs preference collapses it.

$ coolship deploy
→ coolship-example
→ production

✓ Deployed                      0:52
  ✓ build                       0:41
  ✓ rolling update              0:08
  ✓ container                   0:06
  ✓ cleanup                     0:00
Deployment: 03dusayin5rleswixblvdqba
Application: coolship-example (mm4c0zpbrzx8z96t0qiw3tff)
Status: finished
https://coolship.example.com

Piped, in CI, or with --format json, the same run prints status lines, the build log, and one line per stage transition on stderr as they arrive:

$ coolship deploy 2>&1 | cat
Deployment 03dusayin5rleswixblvdqba: queued
Deployment 03dusayin5rleswixblvdqba: in_progress
Starting deployment of joaomnuno/example-coolify-project:main to Master Ubuntu.
Building docker image started.
Stage build: started
Building docker image completed.
Stage build: done
Rolling update started.
Stage rolling update: started
New container started.
Stage container: started
Attempt 2 of 10 | Healthcheck status: "healthy"
New container is healthy.
Stage container: done
Removing old containers.
Stage cleanup: started
Stage cleanup: done
Rolling update completed.
Stage rolling update: done
Deployment 03dusayin5rleswixblvdqba: finished
Deployment: 03dusayin5rleswixblvdqba
Application: coolship-example (mm4c0zpbrzx8z96t0qiw3tff)
Status: finished
https://coolship.example.com

Progress goes to stderr; the final result goes to stdout. The last line is where to look: the application's URL when the deployment finished and the application has a domain, otherwise the deployment's page in Coolify — with --no-wait, when --timeout elapses, and for a preview, whose application URL is the production one. A failed deployment prints the build log gathered so far after the checklist, then names its page on stderr, where the retry lives.

Flags

--logs and --no-logs cannot be combined. Without either, the build_logs key of the preferences file decides; without that, the verbosity does: collapsed at normal, streamed with --verbose or --debug. Piped output and --format json always stream the log.

Examples

coolship deploy                  # wait for the deployment to finish
coolship deploy --logs           # and stream the build log above the checklist
coolship deploy --no-wait        # return the queued deployment UUID
coolship deploy --force          # rebuild without cache
coolship deploy --timeout 20m
coolship deploy api              # named target in a monorepo

Behavior

• Coolship observes exactly the UUID the submission returned, never "the latest deployment", which could belong to someone else.
• States are interpreted as queued, in_progress, finished, failed, and cancelled-by-user. An unknown state is shown as-is and waits for the timeout instead of being guessed.
• Stages come from fixed lines in Coolify's build log (Building docker image started., Rolling update started., New container is healthy., Removing old containers., and their completions and failures), so they need a token that may read the build log. Without one, progress continues without stages or log, and the command says so.
• An observation that stops before the server's verdict — --timeout elapsing, an interrupt, a lost connection — ends the checklist with ✗ Observation stopped, not Deployment failed; the deployment continues on the server. The build log stays collapsed in that case, since nothing failed: only a deployment the server reports as failed or cancelled prints it.
• Interrupting the command stops local waiting only. The remote deployment continues, and the UUID is reported so you can pick it back up.
• An uncertain submission — the request was sent but no answer arrived — is never replayed automatically, because the API defines no idempotency key. Coolship reports what it knows.

JSON

{
  "target": { "…": "the resolved target, see the command reference" },
  "deployment_uuid": "03dusayin5rleswixblvdqba",
  "status": "finished",
  "url": "https://coolship.example.com",
  "url_kind": "application"
}

url is the last line of the human output and url_kind says what it is: application for the application's URL, deployment for its page in Coolify (<instance>/project/<project>/environment/<environment>/application/<application>/deployment/<uuid>). With --no-wait, status is queued and the URL is the deployment page. A failed or cancelled deployment is reported with its state, the deployment page, and a nonzero exit. In JSON mode no progress reaches stdout.

Exit codes

0 when the deployment finished (or, with --no-wait, was queued); 1 when it failed, was cancelled, timed out, or could not be submitted; 2 when the directory is not linked or the target is ambiguous; 130 when interrupted while waiting — the deployment UUID is still printed.