DEPLOYING

Deployments, rollback and history

What happens during a build, how to read the logs, and how to go back to a version that worked.

A deployment is one attempt at taking your source — a commit, a Dockerfile, an image tag — and making it the thing that answers on your URL. Every attempt is recorded, whether it worked or not, and every one of them can be gone back to.

What starts one

The Deploy button: On the application page. Builds the configured branch at its current HEAD.
A push, through a webhook: Connect a Git provider and DockBoard registers the hook itself. A push to the configured branch redeploys; pushes to other branches are ignored.
The API: POST /api/deployments with an application id. This is what a CI pipeline calls — see deploy from CI.
A schedule: Redeploy nightly, or once at a named instant. See scheduled deployments.

At most one deployment per application is in flight at a time. This is enforced by the database, not by a check that could race: a second trigger while one is building is refused rather than queued behind it. Two builds writing the same image tag is not a state worth having.

The statuses, in order

Status	What is happening
`PENDING`	Accepted and queued. Source is being fetched.
`BUILDING`	The image is being built. This is the long part, and the one whose log you want.
`DEPLOYING`	Image built. Containers are being recreated and the reverse proxy regenerated.
`RUNNING`	Success. This is the terminal happy state — there is no separate `SUCCEEDED`.
`FAILED`	The build or the start failed. The previous version is still serving.
`CANCELLED`	You stopped it mid-flight.
`ROLLING_BACK` `ROLLED_BACK`	A rollback is in progress, then finished.

If you poll this from a script, match every terminal status, not just RUNNING. A loop that only breaks on success spins until the CI job times out when a build fails — and a timeout reads as an infrastructure problem rather than a broken commit.

Reading the logs

A deployment carries two logs, and confusing them wastes a lot of time:

Build log: Everything the image build printed — dependency installs, compilation, the Dockerfile steps. A FAILED deployment that never reached DEPLOYING failed here.
Deploy log: What happened once the image existed — container creation, health checks, proxy reload.

Both stream live while the deployment runs, and both are kept afterwards. Container logs — what your application prints once it is up — are somewhere else: the application’s own Logs tab, which follows the running process rather than the deployment that started it.

Container starts, then immediately stops? Read the container log, not the deploy log. The deployment succeeded — it created something that then chose to exit.

Going back to a version that worked

Every deployment in the history has a Rollback action. It redeploys that exact commit, and it is the fastest correct response to a bad release — faster than reverting in Git and pushing, because it skips the round trip through your provider.

Over the API, pass commitSha. It is resolved against this application’s own deployment history, so a SHA it has never deployed is a 400 rather than a silent HEAD deploy.

A rollback moves your code back. It does not move your data back — a migration that ran during the bad release has still run. If the release changed the database shape, roll the schema back deliberately, or restore a backup taken before it.

Cancelling

A running deployment can be cancelled. The request is cooperative: it is recorded, and the build stops at the next point where stopping is safe rather than being killed mid-write. Expect a few seconds, not instant.

Whatever was serving before keeps serving throughout. A cancelled deployment never takes your site down — it just never replaces it.

The history

Each entry records the commit and its message, who triggered it, when it started and finished, how long it took, and both logs. That is enough to answer the two questions that actually get asked after an incident: *what changed*, and *who shipped it*.

Reading the history needs deployments:view; triggering one needs apps:deploy. The two are separate on purpose — see roles.