What is deployment in simple words
The word “deploy” appears in every website publishing instruction, but it is rarely explained. Let's look at it without jargon: what it is, what happens inside step by step, how deployment differs from hosting, and what preview, rollback and production mean.
Definition
Deployment is the publication of finished code where other people can use it. As long as the code is on your computer, it exists for you alone. The deployment transfers it to the server and makes it available at an Internet address.
In relation to a website, deployment means exactly the same as “put out a website” or “publish a website.” In relation to an application or service - “roll out a new version”. Same word, different contexts.
Where did the word come from
From English deploy - “expand”, “place”. Originally a military term: to deploy troops into position. In programming, the meaning has been preserved almost literally - to bring the system into combat readiness at its position, that is, on the server.
In the Russian language, tracing paper has taken root: “deploy”, “deploy”, “roll out”. There is no strict Russian equivalent - “deployment” sounds clerical and is almost never used in conversation.
What happens during deployment
From the outside it is one command, but inside there are four consecutive steps.
1. The platform takes the code
From a GitHub repository, from a folder on your computer, or from an archive, depending on how you launched the deployment.
2. Build
The source code is turned into ready-made files: dependencies are installed, styles and scripts are compiled, images are optimized. The browser does not understand the React or TypeScript sources - it needs regular HTML, CSS and JS, and they are obtained here.
3. Upload
Collected files are sent to storage and distributed to distribution servers. The closer such a server is to the visitor geographically, the faster the website opens.
4. Activation
The site address switches to the new version. This happens at the last moment and instantly, so visitors do not see a half-built site: before the switch, the old version opens, after - the new one.
If an error occurs at any of the steps - for example, the code is not built - the deployment is interrupted, and the previous version continues to work on the site. It is impossible to break a working website with an unsuccessful build in this order.
Deployment, hosting, publication - what's the difference
These words are often used as synonyms, although they mean different things.
| Term | What does it mean | Analogy |
|---|---|---|
| Hosting | The place where the site files are permanently stored and distributed to visitors | Rented apartment |
| Deploy | The action by which the new version of the site gets there | Moving into it |
| Publication | Same as deployment, in everyday language | — |
| Domain | Address where the site is found | House address on the envelope |
| Build | Turning source code into browser-readable files | Assembling furniture from parts |
| CI/CD | Automation that starts the build and deployment itself when the code changes | Conveyor belt |
Words that will appear nearby
A short vocabulary so that the documentation no longer looks incomprehensible.
Preview deployment
Publishing a draft version to a separate address - view and show changes before they go to the main site.
Rollback
Revert to the previous published version. There is no need to rebuild anything - previous versions are already saved.
Branch
Parallel development line. Allows you to make edits without touching what already works for users.
Production
The main, “combat” environment is what real visitors see. As opposed to test.
Static
Website from pre-prepared files. All visitors are given the same thing - quickly and cheaply.
SSR
Server rendering: the page is rendered at the time of request. Needed when the content is user or data specific.
How different types of sites are deployed
The word is one, but behind it there are noticeably different processes. The difference is whether something is needed execute on the server at the moment when the visitor opens the page.
Static site
Landing page, portfolio, documentation, blog on a static generator. All pages are prepared in advance, the server simply delivers the finished files. Deployment boils down to spreading the files across distribution servers and switching the address. This is the fastest and cheapest option: there is nothing to break, such a site can handle almost any load.
Site with server rendering (SSR)
The page is built at the time of request - this is how Next.js, Nuxt and similar frameworks work, when the content depends on the user, cart or fresh data. Here the deployment is more complicated: you need to not only upload the files, but also start a process that will respond to requests, and carefully stop the old one, without interrupting those who have already opened the page.
Backend and API
For a service that provides data to an application, database migrations are added to the deployment. This is a separate difficulty: the code can be rolled back instantly, but changes in the structure of the database are not always possible. Therefore, migrations are written so that the old and new versions of the code work with the database simultaneously for some time.
In practice, this difference is little visible to you as the site author: the platform determines the type of project itself and selects the appropriate scenario. It is useful to know about it in order to understand why deploying a landing page takes seconds, and rolling out a large service takes minutes.
Three misconceptions about deployment
“Deploy must be done at night”
A habit of those times when publication meant website downtime. Modern version switching is instantaneous, and the time of day does not matter. At night it’s worse - if something breaks, a sleep-deprived person will have to fix it.
“The less often you deploy, the safer”
Vice versa. Rare rollouts mean that many changes have accumulated in each, and if a breakdown occurs, it is not clear which of them is to blame. Frequent small deployments get fixed faster.
“An unsuccessful deployment breaks the site”
If the build crashes, publishing simply doesn't happen - visitors continue to see the previous working version. And if it breaks after publication, rolling back to the previous version helps.
What deployment looks like today
Ten years ago, deployment was an event: you chose a quiet night, went to the server, copied files, restarted processes, then spent a long time checking that nothing had fallen off. They rolled out rarely - once a month or less - because every time it was a risk.
Now deployment is a routine. Changes are published as soon as they are ready, several times a day. Here's what has changed:
- Build is performed on the platform side, and not on the developer’s computer - the result no longer depends on who has what version of the environment.
- Switching to the new version is instant, therefore the site does not “blink” during publication.
- Rollback made cheaper, than repair: if the version is unsuccessful, it is simply returned back with one button.
- Each branch receives its own address, and changes are shown to the customer before they reach the main site.
In practice, it looks like this: you save changes in the repository or execute one command - and after half a minute a new version of the site opens for visitors. Everything described above happens internally and does not require your participation.
Try deployment in practice
One command - npx layero@latest deploy - and a website on the Internet. Free plan, HTTPS and CDN in Russia.