Frontend Deployment

Every website roughly consists of two halves. One half is what you see in the browser: buttons, text, images, menus. The other half runs invisibly on remote machines and manages things like user accounts or orders. The visible half is called the frontend. Frontend deployment is the process by which a new version of this visible half is transferred to the machines that deliver it to all visitors. Before that, the change only exists on the developer’s laptop; afterward, everyone gets to see it.

The moment when changes become real

As long as code hasn’t been rolled out, it has no value to users. A team can work for months on a new checkout process. Only the deployment decides whether this process is actually used. That’s why the frequency of deployments is considered a metric of speed in many companies.

Large providers roll out their frontend several times a day. Other companies only manage it every few weeks. The difference is rarely the quality of the programmers. It usually comes down to how automated the process is and how easily errors can be reverted.

At the same time, deployment is the point with the highest risk. A faulty frontend won’t bring down a database, but it can make the entire site unusable. A broken button in the shopping cart directly costs an online shop revenue. That’s why teams invest a lot of effort into making the process boring and predictable.

From source code to delivered page

At the start there is the source code, meaning the program code written by humans. This is usually not directly suitable for browsers. A program called a build tool therefore translates it into compact files. In the process, whitespace is removed, files are merged, and images are shrunk. The result is a folder of finished files, the so-called build.

Before this build is published, automated checks run. Tests verify that important workflows still work. Often a preview version is also created under a secret address. There, the team looks at the change before it goes live on the real domain.

For delivery, the files end up on a Content Delivery Network, or CDN for short. This is a network of servers in many countries that keeps copies of the files ready. A visitor in Hamburg thus gets them from a nearby data center instead of from California. Two strategies are popular for the moment of switchover: with blue-green deployment, the new version is fully ready, and then traffic is redirected all at once. With canary release, only a small percentage of users initially receive the new version.

How you notice a deployment as a user

Usually you don’t notice anything at all, and that’s exactly the goal. It only becomes noticeable when something goes wrong. If an app suddenly looks strange or a message appears like “New version available, please reload”, a fresh deployment is often behind it. Maintenance pages saying you’ll be back shortly also fall into this category.

In tech industry news, the term comes up when explaining outages. Companies then write that a faulty rollout was the cause and that they rolled back. Rolling back means: reactivating the previous version. With a cleanly set up frontend, this often takes less than a minute.

A common misconception is that deployment is the same as programming or the same as hosting. Programming produces the code, hosting refers to the ongoing operation of the servers. Deployment is the process in between, meaning the handover. Providers like Vercel, Netlify, or GitHub Pages have turned this into a business model: you connect your code repository, and every saved change automatically triggers a new deployment.