Promote & roll back

Once a change is reviewed on a preview, promoting it to production is one action. Every deploy is recorded as a release, so if a promotion goes wrong you can roll back to the previous one immediately — or restore from a snapshot taken before the change.

Promote to production

Promotion ships a reviewed branch’s build to the production environment. The most direct path is a git push of the promoted branch to your default branch, which deploys live:

Promote by merging to the default branch

git checkout main
git merge --ff-only feature/checkout
git push managed main

You can also promote directly from the dashboard or the API without going through a merge, when the build you reviewed is exactly the build you want live.

Dashboard

Open the site’s Deploys tab, find the build you reviewed on its preview, and choose Promote to production. managed.dev rolls the same content-addressed, signed artifact onto production — no rebuild.

The Deploys tab in the dashboard with a preview build selected and a “Promote to production” action, showing the production environment as the target and a confirmation summary.

API

Promotion is an async job — it returns 202 Accepted with a job to track.

Promote a build to production

curl -X POST https://api.managed.dev/v1/sites/site_01J7.../deployments \
  -H "Authorization: Bearer mfk_live_..." \
  -H "Idempotency-Key: 1c8f...e2" \
  -H "Content-Type: application/json" \
  -d '{ "build_id": "build_01J8...", "target": "production" }'

Gate promotion on a clean preview

Before you promote, check the preview’s traces filtered to errors and its web vitals. Promoting only when the preview is clean turns “we’ll find out in production” into “we already know”.

Deployment history & releases

Every deploy to every environment is recorded. Production’s history is the list of releases that have served the live site, each tied to a commit, a build, and a timestamp. The history is your audit trail for “what was live when” and the menu you roll back from.

The deployment history for the production environment, listing recent releases with commit SHA, build ID, deploy time, and a “Roll back to this release” action on each prior entry.

Instant rollback

A rollback re-points production at a previous release. Because the artifact is content-addressed and already built, rolling back is a roll, not a rebuild — it’s fast and deterministic.

1. Open the production environment’s deployment history.
2. Pick the last known-good release.
3. Choose Roll back to this release and confirm.

Rollback affects code, not necessarily data

Rolling back a release restores the code/artifact that was live. If the problematic deploy also ran a database migration, you may need to restore data too — roll back from a snapshot taken before the deploy to bring code and data back together.

Roll back from a snapshot

When you need data as well as code, restore a point-in-time snapshot. A snapshot restore brings back the database and files as they were at capture time. The habit worth building: take a snapshot immediately before any risky promotion, so you always have a clean restore point.

Restore a snapshot

curl -X POST https://api.managed.dev/v1/sites/site_01J7.../snapshots/snap_01J8.../restore \
  -H "Authorization: Bearer mfk_live_..." \
  -H "Idempotency-Key: 9a2b...77"

Promote vs clone-content

Promotion ships code from one environment to production. When what you actually want is to move content — for example pull production’s fresh database down into staging, or push staging’s content up — use clone-content instead. It’s directional and lets you choose the database, files, or both, with a dry-run.

You want to…	Use
Ship reviewed code to production	Promote
Refresh an environment’s data from another	clone-content (directional)
Bring back code and data after a bad deploy	snapshot restore

Next steps

Snapshots & backupsPoint-in-time captures you can restore in a click — your rollback safety net.

The build pipelineWhy a content-addressed, signed artifact makes promote and rollback a roll, not a rebuild.