Deploy safely with a way to roll back

Guide · checked against the docs on Oct 15, 2026

Every deploy can break something. The fix is to have a way back before you need one. Vercel describes rollback as useful "in situations that require a swift recovery from production incidents, like breaking changes or bugs." (source)

This guide is a checklist of 8 checks for anyone shipping a small web app built with AI coding agents. It's quoted from Vercel, Cloudflare, Netlify, Git, Supabase and Google SRE docs, checked Oct 2026.

Not affiliated with or endorsed by Vercel, Cloudflare, Netlify, the Git project, Supabase or Google. Check their current docs before relying on these details.

For backing up your database, see Before you ship: lock the database, back it up, and log what happens. This guide doesn't repeat it.

Part 1: Test before it's live

Check 1: Deploy to a preview first

Vercel explains: "Preview environments allow you to deploy and test changes in a live setting, without affecting your production site." (source)

By default, Vercel makes a preview deployment when you push a commit to a branch that isn't your production branch, open a pull request, or deploy with the CLI without the --prod flag (checked Oct 2026). One exception: "The first deployment of a new project is always a production deployment." (source)

Vercel also says: "Use a staging workflow to test changes before serving them on your production domains." Which staging options you get depends on your plan (checked Oct 2026). (source)

New changes go to a preview first, not straight to production.
You click through the preview before it goes live.

Check 2: Promote the build you tested

Rebuilding can give you something slightly different from what you tested. Vercel lets you promote an existing deployment instead: "Promote a staged production build: You can use this option to promote a production deployment which has never served production traffic." Then: "Once promoted, the deployment is marked as Current." (checked Oct 2026) (source)

You can also promote a preview: "There may be times when you need to promote an existing preview deployment to production, such as when you need to temporarily use a branch that isn't set as the production branch." (source)

Where your host supports it, you promote the exact deployment you checked.

Part 2: Know your way back

Check 3: Find your host's rollback button before you need it

Each host does it a little differently (checked Oct 2026):

Vercel: Instant Rollback lets you "Recover from a bad production deployment by rolling back, investigating the root cause, and redeploying a fix." How far back you can go depends on your plan. (source)
Netlify: "If you need to roll back, you can publish one of the previous deploys listed in the UI as the live version of your site in production." It "doesn’t trigger a new deploy" and "Rollbacks are instantaneous." (source)
Cloudflare Pages: "Any production deployment that has been successfully built is a valid rollback target." But: "Note that preview deployments are not valid rollback targets." (source)
Cloudflare Workers: "To roll back to a specified version of your Worker via Wrangler, use the wrangler rollback command." (source)

You know where your host's rollback option is and who on your team can use it.

Check 4: After a rollback, check what your next push will do

A rollback can be undone by accident, or it can quietly stop new deploys.

Vercel: after a rollback, "new pushes to your production branch won't go live automatically." Once you undo the rollback, "New pushes to your production branch will go live automatically again." (source)
Netlify: "If your Netlify site is connected to a Git repository and has auto publishing turned on, any new Git-triggered production deploys will overwrite the previously rolled back version." Netlify also has locked deploys, which let you pin "a site to the latest published deploy for the time being." (source)

After a rollback, you know whether your next push goes live on its own.
You fix the bug before pushing again, so the bad version doesn't come back.

Check 5: Undo shared code with git revert, not git reset --hard

Git's docs describe the difference: "git-revert[1] is about making a new commit that reverts the changes made by other commits." By contrast, "git-reset[1] is about updating your branch, moving the tip in order to add or remove commits from the branch. This operation changes the commit history." (source)

Revert keeps the history: "git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one)." (source) Be careful with merges, though: "Reverting a merge commit declares that you will never want the tree changes brought in by the merge." (source)

Reset with --hard can lose work: "--hard Overwrite all files and directories with the version from <commit>, and may overwrite untracked files." (source)

git revert <commit>

To undo a commit that's already been shared, you use git revert.
You don't run git reset --hard unless you're sure you can lose local changes.

See git basics for AI coders for the basics.

Part 3: Your data doesn't roll back

Check 6: Rolling back code doesn't roll back your database

Cloudflare says it plainly: "Resources connected to your Worker will not be changed during a rollback." And: "You cannot roll back to a previous version of your Worker if the Cloudflare Developer Platform resources (such as KV and D1) have been deleted or modified between the version selected to roll back to and the version in the active deployment." (checked Oct 2026) (source)

Our advice, not a vendor quote: the same idea applies on any host. If a deploy changed or deleted data, rolling back the site won't bring it back. Confirm you have a working backup before any deploy that changes data, using our database backups checklist.

You've confirmed a backup before deploys that change data.

Check 7: Change the database only through migration files

Supabase defines them: "Database migrations are SQL statements that create, update, or delete your existing database schemas." With them, "All of your database changes are captured in code, and you can reset to a known state at any time, complete with seed data." (source)

Test locally first: "Test your new migration file by resetting your local database." (source) That reset (supabase db reset) wipes and rebuilds your local database. Use it only on your local copy, never on your live database.

Don't edit the live database by hand: "Making schema changes directly on your remote database (via the SQL editor or Table Editor) bypasses the migration history and will cause db push to fail with sync errors." And: "Once you're using migrations, all schema changes to your remote database should go through migration files only." (checked Oct 2026) (source)

Every schema change is a migration file.
You test each migration on your local database before pushing it.
Nobody edits the live schema in the SQL editor or Table Editor.

Part 4: Ship small, roll out slowly

Check 8: Ship small changes and roll out gradually

Google's SRE Workbook says: "Smaller, self-contained release artifacts make it cheaper and easier to roll back any given release artifact in the event of a bug." It defines canarying "as a partial and time-limited deployment of a change in a service and its evaluation." If errors rise, "this signals the canary deployment is 'bad.' In response, we should pause and roll back the deployment, or perhaps contact a human to help troubleshoot the issue." (source)

Some hosts support this directly. On Cloudflare Workers, "you can route a percentage of requests to the new version while the rest continue to be handled by the previous version." Cloudflare suggests you "Monitor error rates and exceptions across versions using observability tooling" and "Roll back to a previously stable version if you notice issues" (checked Oct 2026). (source)

One caution: "Because gradual deployments mean multiple versions of your Worker serve traffic simultaneously, clients and services can end up interacting with more than one version in ways that produce errors or inconsistent behavior." (source)

Each deploy changes one thing you can undo on its own.
Where your host supports it, you send a small share of traffic to the new version first.
You watch errors after each deploy and roll back if they rise.

Tell your agent how to deploy

Add a rule like this to your agent's instructions (we haven't tried it ourselves):

Never run git reset --hard, force-push, or edit the production
database directly. Deploy to a preview first, and tell me the
rollback steps before anything goes to production.

See AI agent permissions for beginners to make the agent ask before it runs risky commands.

Next steps

Back up before you change data: lock the database, back it up, and log what happens
Control what your agent can run: AI agent permissions for beginners
Get an undo button for code: git basics for AI coders

Sources

All checked Oct 15, 2026:

Not affiliated with or endorsed by Vercel, Cloudflare, Netlify, the Git project, Supabase or Google. Check their current docs before relying on these details.