# Deploy: how your app reaches the internet and how to go back

> How an app reaches the internet, what the difference is between a preview and production, and how to return to an earlier version if a deployment goes wrong.

*Tags: ai, deployment, production, ux-for-ai*

---


> [!info] Quick Definition
> **Deploying** means publishing a version of your app at an address reachable from the internet. Modern platforms let you test each version before anyone sees it and go back to an earlier one if something goes wrong.


## How does an app reach the internet?

Your app lives on your computer while you develop it. For someone to use it, it has to be copied to a server that serves it and given an address. That step is the deployment. On many platforms it is enough to connect the repository (see [[git-for-designers|Git for designers]]): each time you push a change, a deployment is created automatically.

Vercel's documentation, checked on October 30, 2026, defines a deployment as the result of a successful build of the project, and each one gets a unique URL so you can see the changes in a live environment. The most common way to create one is pushing code to a connected repository: each commit or pull request triggers a new deployment. You can also deploy from the command line, by dragging a folder into the browser (Vercel Drop), with an activation link (a deploy hook) or through the API ([Vercel, Deploying to Vercel](https://vercel.com/docs/deployments)).

## What is the difference between a preview and production?

| Type | What it is for | Who sees it |
|---|---|---|
| Preview | Testing a change without affecting the live site | Whoever has access to its URL; depending on the platform and its settings, it may be public or protected |
| Production | The official version, at the main domain | Real users |

Vercel separates three environments: local (your computer), preview and production, and lets you promote a preview to production once it is tested. The golden rule is not to test in production. The preview is where you see the change with realistic test data, with someone who did not build it, and only then promote it.

## What do you do when a deployment goes wrong?

First restore the service; second, understand what happened. Vercel's guide for recovering from a broken deployment follows that order: confirm that production is broken (look at the error logs or user reports), go back to an earlier deployment, check that the errors dropped and only then look for the cause ([Vercel, Rolling back a production deployment](https://vercel.com/docs/deployments/rollback-production-deployment)).

According to that guide, the rollback points production traffic at an earlier deployment without rebuilding the project. It happens at the routing layer, so it takes effect within seconds. The scope depends on the plan: on Hobby you can only return to the immediately previous production deployment, while on Pro and Enterprise you can choose any.

With service restored, the guide suggests identifying the deployment that failed, checking its build logs (for example, for missing environment variables) and comparing its errors with those of the last deployment that worked. Then you fix it, test it in a preview and promote it to production. If the failure comes from an AI-made change, the search for the cause resembles the method in [[debugging-with-ai|debugging with AI]]. If the deployment touches data or payments, review [[when-not-to-vibe-code|when not to vibe code]] first.

## Does it work the same on other platforms?

The idea repeats, with differences that matter. According to the documentation checked today:

- **Netlify** generates Deploy Previews from pull requests, merge requests or agent runs. To go back, the **Publish Deploy** button on an earlier successful deploy publishes it without building again, and Netlify says the rollback is instantaneous. Careful: with auto publishing on, the next production deploy overwrites the restored version; you have to lock it with *Lock to stop auto publishing* ([Netlify, Manage deploys](https://docs.netlify.com/deploy/manage-deploys/manage-deploys-overview/)).
- **Cloudflare Workers** lets you roll back to an earlier version, which becomes a new deployment, but only among the 100 most recently published versions. A rollback does not change connected resources, such as databases: if the data structure changed, the old code may fail ([Cloudflare, Rollbacks](https://developers.cloudflare.com/workers/configuration/versions-and-deployments/rollbacks/)).
- **Cloudflare Pages** creates preview addresses that are public by default; Cloudflare Access restricts them to your account ([Cloudflare, Preview deployments](https://developers.cloudflare.com/pages/configuration/preview-deployments/)).

What holds everywhere: going back changes the code, not the data. If your change also modified a database, reverting the app may not be enough.

## What should you check before publishing?

For an AI-made change, four points are enough for a prototype:

1. **The preview with a real account.** Test the main flow, not just whether the screen loads. Ask someone who did not build it to run it and tell you what they did not understand.
2. **The error logs.** A screen can look fine while the server fails silently. Vercel, for example, lets you filter a preview's logs by error level.
3. **The secrets.** Keys must not appear in code that reaches the browser. See [[environment-variables-and-secrets|environment variables and secrets]] and [[vibe-coding-security-basics|security basics for vibe coding]].
4. **The way back.** Before promoting, note the URL of the current deployment that works. If something fails, you will not have to hunt for it at the most stressful moment. Also note the publishing time and what changed.

Publishing early does not mean publishing without a way back, as in the flow of [[idea-to-app-in-a-day|idea to app in a day]]. A deployment is also a calendar decision: publish big changes when someone can watch the logs afterwards. A failed deployment is one more error the user has to be able to recover from; see [[ai-errors-and-recovery|AI errors and how to recover]].

## Example

Illustrative example: a designer publishes a new pricing page. Ten minutes after promoting the change, support reports that the buy button shows an error. She rolls production back to the previous deployment, checks in the logs that the errors dropped and stops touching production. Then she opens the preview of the same change, finds that an environment variable was not set in production, fixes it and promotes the corrected version. Service came back before the cause was investigated, which is what mattered.

## Common mistakes

- Testing changes directly in production.
- Promoting a change without checking the error logs.
- Not knowing which earlier deployment worked.
- Rolling back the code and forgetting that the data does not roll back with it.
- Treating deployment as the end of the work, when it is only the start of verification.
- Leaving a service key in code that reaches the browser.
- Investigating the cause while users still see the error.

## Sources

- [Vercel, "Deploying to Vercel"](https://vercel.com/docs/deployments): definition of a deployment, unique URL, ways to deploy and the local, preview and production environments.
- [Vercel, "Rolling back a production deployment"](https://vercel.com/docs/deployments/rollback-production-deployment): recovery order, rollback without rebuilding and the Hobby limit versus Pro and Enterprise.
- [Netlify, "Manage deploys"](https://docs.netlify.com/deploy/manage-deploys/manage-deploys-overview/): Publish Deploy and locking auto publishing.
- [Netlify, "Deploy overview"](https://docs.netlify.com/deploy/deploy-overview/): Deploy Previews.
- [Cloudflare, "Rollbacks" (Workers)](https://developers.cloudflare.com/workers/configuration/versions-and-deployments/rollbacks/): rollback to one of the 100 most recent versions and resources that do not change.
- [Cloudflare, "Preview deployments" (Pages)](https://developers.cloudflare.com/pages/configuration/preview-deployments/): previews public by default and Cloudflare Access.


---

Source: https://www.fernandoux.com/en/wiki/ai/deploy-for-designers/