Deployments and rollbacks

A deployment is one release of a service in one environment: build (for GitHub sources), then rollout.

Lifecycle

queued → building → deploying → success
                              ↘ failed | crashed

• queued: waiting for a build slot.
• building: cloning and building the image (GitHub sources only; images and templates skip this).
• deploying: rolling out the new version.
• success: the new version is running and receiving traffic.
• failed: the build or rollout failed. The previous successful deployment keeps running.
• crashed: the container started but keeps exiting. Check the runtime logs.

Each deployment records its trigger (for example a git push, a manual deploy, a configuration change, a redeploy or a rollback), the commit, who started it and, for generated builds, the detected build plan.

What starts a deployment

• A push to the service's branch (if watch paths are set, only when a matching file changed).
• Deploy in the dashboard, fjordrun deploy in the CLI, or the API (POST /api/v1/services/{id}/deploy).
• Redeploy on an existing deployment.
• A change to a running service: saving its variables, settings or source, or attaching or deleting a volume, redeploys it automatically. Changing a shared variable redeploys the running services that reference it.

Changing a variable of one service does not redeploy the other services that reference it with ${{Service.VAR}}. Redeploy them to pick up the new value.

Rollbacks

Open the service's Deployments tab and choose Rollback on an earlier deployment that succeeded. Fjordrun deploys the exact image that deployment built, without rebuilding. Only deployments that succeeded (or were later replaced) can be rolled back to.

The rollback uses the service's current variables and settings, not the ones from the time of the old deployment.

Cancelling

A deployment that is still queued, building or deploying can be cancelled. The running version stays in place.