Deployment is the act of releasing a version of your website or app so people can use it. The code a developer writes on their laptop does nothing for customers until it is built, copied to a server and switched on. That whole step, from "finished" to "live", is a deployment, and each release is often called a deploy.
What happens during a website deploy
- Pick a version. Usually the latest commit on the main branch.
- Build. Source code is turned into the files browsers actually load: bundled JavaScript, compiled CSS, optimized images. A React site built with Vite, for example, produces a
distfolder of static files. - Upload. The build output goes to hosting, a server or a CDN.
- Switch traffic. The domain starts serving the new version. Good platforms do this atomically, so visitors never see a half-updated site.
- Verify. Someone or something checks the live site actually works.
Some deploys also run database migrations or update environment settings, which is where most of the risk sits.
Manual versus automated releases
The old way was dragging files onto a server over FTP. Today most sites deploy automatically: a host such as Vercel, Netlify or Cloudflare Pages watches a Git repository and runs a fresh deploy whenever the main branch changes. That automation is the "CD" in CI/CD. Each deploy is kept, so going back means promoting an older one rather than rebuilding.
Example: an atomic deploy and an instant rollback
A gym publishes a new class timetable at 9am. At 9:10 a member reports that the sign-up button does nothing. On Vercel or Netlify, the owner's developer opens the deployments list and promotes the 8am deploy back to live; the old version is serving again within seconds while the bug is fixed calmly.
When deployment matters for a small business
If you use an all-in-one builder, "Publish" is your deployment and you rarely need to think further. With a custom site, ask two questions: how does a change get from the developer to the live site, and how fast can a bad release be undone? A clear answer to both matters more than any specific tool. We.Inc publishes generated sites to a custom domain with free SSL, which is a deployment handled for you.
Deployment mistakes
- Deploying on Friday evening. Release when someone is around to watch and fix problems.
- Testing only on the developer's machine. Use a staging environment or a preview deploy.
- Forgetting environment variables. A site that works locally fails live because an API key was never set on the host.
- No rollback. Know how to restore the previous version before you need to.
Related terms
- CI/CD: automating tests and deploys.
- Production environment: the destination of a release.
- Staging environment: a rehearsal space before deploying.
- Web hosting: where deployed files live.