Deploying and rolling back#

The deployment commands, what each one replays, and how to recover.

Before you start#

A linked project directory and an active session. See Your first deploy.

Commands#

Command	Effect
`midnight up`	Deploy from source using the current session
`midnight redeploy`	Queue an immutable image and configuration replay
`midnight rollback --previous`	Return to the previous deployment
`midnight restart`	Restart the running workload
`midnight stop`	Stop the workload
`midnight cancel`	Cancel the latest queued or running linked deployment
`midnight remove --deployment dep_...`	Remove a specific deployment
`midnight open`	Open the service

Deploy from source#

midnight up

The build path autodetects the project shape, or uses a Dockerfile when one is present, checks out the git source, generates SBOM and provenance artefacts, and pushes to the registry.

Note

Midnight produces SBOM and provenance artefacts. It does not claim a SLSA Build Level, and it does not automatically publish signed attestations.

Replay an existing deployment#

midnight redeploy

redeploy replays an immutable image and configuration. It does not rebuild from source, so it reproduces exactly what ran before — useful when you want to rule out a source change as the cause of a problem.

Roll back#

midnight rollback --previous

Rollback returns the service to its previous deployment.

Warning

Rollback returns the deployment. It does not undo a database migration your application ran, and it does not revert variables you changed. Decide what else needs reversing before you rely on it.

Cancel#

midnight cancel

Cancels the latest queued or running deployment for the linked service. Use it when a deploy is in progress and you already know it is wrong — cancelling is cheaper than deploying over it.

Deployment records#

Every deployment is a record with a state. The control plane holds a canonical deployments table with a database-level guard enforcing legal state transitions, so a deployment cannot silently occupy an impossible state.

That is what makes the records worth reading during an incident: the state you see is a state the system permitted.

Retrying safely#

Creation and update commands accept --idempotency-key. When you omit it, the CLI derives a stable key from the request intent.

If a response is lost or uncertain, retry with the same explicit key and unchanged arguments rather than starting a new mutation. Starting a new one risks two of whatever you were creating.

Verify#

midnight status shows the expected link.
midnight logs -f shows the deploy progressing.
After a rollback, the running deployment is the previous one.

If it does not work#

Symptom	Check	Recovery
Deploy queued but never starts	Worker and buildkit units	See Install the server
Build fails on source detection	Whether a Dockerfile is present and correct	Add one rather than fighting autodetection
`up` refuses with a credential error	Session scope	It will not fall back to a recovery credential
Rollback succeeded but the app still misbehaves	Whether a migration or variable change also needs reversing	Rollback covers the deployment only
An uncertain retry created a duplicate	Whether an idempotency key was reused	Reuse the same key on retry
Deploy succeeded but nothing is reachable	Routing	See Domains and TLS