# deploy Deploy the linked application using the source and branch already configured in Coolify, and observe exactly that deployment. URL: https://coolship.itrocas.com/docs/commands/deploy ```text 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](https://coolship.itrocas.com/docs/concepts/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. ```text $ 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: ```text $ 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 | Flag | Purpose | | -------------------- | ---------------------------------------------------------------------------------------- | | `--no-wait` | Return after submission without observing completion. | | `--force` | Force Coolify to rebuild without cache. | | `--timeout DURATION` | Maximum time to wait for deployment completion (default `10m0s`). | | `--logs` | Stream the build log live above the checklist (terminal only). | | `--no-logs` | Keep the build log collapsed; it prints in full if the deployment fails (terminal only). | `--logs` and `--no-logs` cannot be combined. Without either, the `build_logs` key of the [preferences file](https://coolship.itrocas.com/docs/commands/config) decides; without that, the [verbosity](https://coolship.itrocas.com/docs/platform/output#verbosity) does: collapsed at normal, streamed with `--verbose` or `--debug`. Piped output and `--format json` always stream the log. ## Examples ```bash 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 ```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 (`/project//environment//application//deployment/`). 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.