How to Roll Back a Netlify Deploy

Here's how to roll back a Netlify deploy using an earlier successful version in the dashboard. You need access to the project and a deploy that's still available. The action republishes existing output; it doesn't run a new build of the old source.

How to roll back a Netlify deploy without the next commit undoing it

The surprising detail is that rollback doesn't freeze publishing. If Git-triggered production deploys remain automatic, the next one can replace the version you just restored. Netlify's documented Lock to stop auto publishing control keeps new builds from automatically becoming the main site.

The Manage deploys documentation confirms the rollback and lock behavior. My preference during a broken-release fix is to restore a known version, keep production pinned and review the correction before resuming publishing.

Find the product background on the Netlify project page. The Cloud & Hosting category includes other deployment services.

1. Identify the last version that did the job correctly

Open the project's Deploys list and find an earlier successful deploy. Netlify documents filters for time frame, deploy context and deploy status. Use the production history to identify the relevant version; a recent preview isn't automatically the same thing as a known working production release.

Record the selected deploy's identity and the change you're trying to undo. A homepage typo might point to the last content update. A broken navigation component might point to a code change. That distinction helps you choose the version that actually removes the problem.

Don't choose only by age. An older deploy may contain another issue you already fixed. Compare the visible page or feature you want back with the release information you have before making it the main site.

2. Open the successful deploy's detail page

Select the chosen successful entry and open its details. The official guide places Publish Deploy on the detail page of a successful deploy. This action publishes the existing atomic deploy while it remains available.

My recommendation is to inspect its deploy-specific URL first if it's available. Open the affected page there and verify the expected result. For a navigation problem, use the actual destination link; a successful homepage load doesn't establish that the menu route is correct.

A build status tells you that the output was created successfully. It doesn't tell you whether the output contains the right headline or a correct product link. Choose a version based on the public behavior you need to restore.

3. Publish the existing deploy

Select Publish Deploy for the chosen successful version. Netlify documents this as a rollback without a new build. You're choosing previously generated output for production, so the source repository doesn't automatically change with it.

Open the project's main public address and inspect the affected page. Record the visible result alongside the deploy you selected. This establishes which output visitors are receiving, separate from which commit now sits at the repository's branch tip.

Keep the current source history intact while preparing a fix. Republishing an old deploy and reverting a source commit are different operations. The corrected source should eventually produce a new successful release, even if the restored output is serving visitors in the meantime.

4. Lock automatic publishing while you fix the source

Return to Deploys and select Lock to stop auto publishing. Netlify says new deploys can still be built while the main site remains pinned to the published version. That lets the team inspect corrections without immediately replacing the restored site.

This is different from stopping builds. The separate build-status control stops production builds, preview builds and branch builds. Use the publishing lock when you want to keep creating reviewable output while holding the public version steady.

Tell collaborators which version is pinned and where to inspect the next candidate. A correction can be ready in a preview without being live on the main domain. Keeping those two addresses clearly identified avoids someone checking the wrong page and declaring the release finished.

5. Review the fix, then resume publishing

Put the correction through the intended source workflow. Inspect the new deployment's affected page and any nearby links or assets. For a broken image path, check the actual image; for a navigation change, check both the menu and its destination.

When the corrected release is ready, publish the intended version and use Unlock to start auto publishing to resume the normal flow. The documented button lives in the same Deploys list.

Record the version now serving the main domain. The incident isn't complete merely because automatic publishing was resumed; the public site must contain the correction you meant to ship.

Known problems

The old deploy has disappeared

Netlify's current documentation says automatically deleted deploys disappear from the dashboard and API, with their permalinks returning a generic 404. Rollback needs a deploy that's still available. If the desired artifact is gone, prepare a fresh build from retained source instead of searching for a nonexistent publish button.

An older Netlify support discussion about deploy history shows why people ask about which artifacts are retained. Its historical replies shouldn't replace today's documented deletion rules. Keep source history independently of the dashboard's artifact history.

A new commit replaces the restored version

Automatic production publishing is still active. Use the publishing lock, then inspect the intended correction before resuming. Repeating the rollback without changing that control leaves the same trigger ready to replace production again.

The page returns but application data is wrong

Restoring website output doesn't promise to restore an external database. Netlify Database has its own documented backup and recovery behavior, including on-publish backups; a separate database provider has its own recovery route. Identify the data system before treating a page rollback as a data repair.

Troubleshooting table

Three variations

For a static content mistake, select the previous output that contains the correct content. Inspect the specific page before and after publishing; a working homepage alone doesn't prove a changed article is restored.

For a code regression, keep the old output public while correcting the source. A new preview can show the fix without putting it on the main domain immediately.

For a planned content freeze, lock automatic publishing and keep builds available for review. Stop builds only when preventing new build work is itself the goal.

Completion checklist

• The chosen deploy is successful and still available.
• The main site shows the intended restored behavior.
• Automatic publishing is locked if production must stay pinned.
• The repository contains or is preparing a corrected source version.
• The corrected public version is confirmed before normal publishing resumes.

FAQ

Does Netlify rollback rebuild the old commit?

No, Publish Deploy republishes an existing successful atomic deploy that's still available. It doesn't trigger a new build. That makes the published output and the repository branch two separate things to track; prepare a source correction so the next normal deployment produces the behavior you intend to keep.

Does locking a Netlify deploy stop builds?

No, a publishing lock keeps new deploys from automatically replacing the main site while allowing builds to continue. Stopping builds is a separate control with a wider effect on production, preview and branch builds. Use the lock when you want to review a correction without changing the version visitors receive.

Can I roll back to a deleted deploy?

No, the documented rollback route needs an available successful deploy. Deleted artifacts and their permalinks are unavailable. Retained source history can supply a fresh build of an earlier version, but that is another build and deployment job; it isn't republishing the artifact that has been removed.

Next steps

Compare Netlify and Vercel if rollback and team access shape your hosting decision. Vercel, Codeberg and Framer offer different publication routes. Browse Development & Technology for the tools around your source workflow.

Sources

Netlify Manage deploys, Stop or activate builds, deploy overview and Netlify Database backup/recovery documentation; linked historical support discussion. Documentation checked October 9, 2026.