Continuous Deployment
Definition
Continuous deployment is an arrangement in which the path from an approved change to a live site is fully automated. Someone merges a change; a service notices; it installs dependencies, runs the tests, runs the build step and publishes the result. If any stage fails, nothing is published and the previous version stays live. It is often confused with continuous delivery, which does all the same work but stops one step short and waits for a person to approve the release — the distinction is exactly one button. The approach suits sites that change often and can tolerate a bad change being fixed forwards. It fits a marketing site far better than it fits medical software.
Why It Matters
Manual publishing does not scale with the number of people making changes, and it fails in a specific way: the one person who knows how to publish goes on holiday. Automating the path also makes it uniform, so the site is built the same way every time instead of on whichever laptop was open. The measurable effect is lead time, the gap between a change being finished and being visible, which teams commonly cut from days to under ten minutes. Small frequent changes are also far easier to diagnose than one large quarterly release. The trade is that mistakes reach the public quickly too, which is why this is normally paired with a deploy preview and a fast way back.
How It Works
A webhook fires when a branch is updated. A runner starts a clean container, checks out the code, restores a dependency cache and executes the project's build command. Tests and checks run in the same container, and a non-zero exit code stops the pipeline there. On success the runner takes the build artifact and sends it to the host, commonly as a zip posted to a REST API with a token in the Authorization header. The host stores it as a new release and switches traffic to it. For a modest static site the whole loop takes between forty seconds and three minutes, most of it spent installing dependencies.
Real-World Example
A three-person team keeps its internal handbook as a static site. They already run a job that builds the site on every merge to the main branch; the last step of that job posts the built folder to the hosting API, so 'handbook.99helpers.site' is updated about a minute after a change is approved. It is worth being clear about where the automation lives. The host here is a drop-a-file service with an API, not a build service — it never checks out the repository and never runs the build. If the team dragged the built folder in by hand instead, the result would be byte for byte identical; only the trigger would differ, and for a site that changes twice a month, dragging is honestly less work.
Common Mistakes
- ✕Automating publishing before there are any checks worth running — the pipeline then reliably delivers broken versions faster than a person would
- ✕Assuming the host runs the build because it hosts the site — a file host serves whatever folder it is given, so the build has to happen somewhere first
- ✕Storing the publishing token in the repository — anyone who can read the code can then replace the live site
Related Terms
Deployment
A deployment is the act of putting a new version of a site or file where the public can reach it. It is the moment the version you have been working on becomes the version visitors get.
Build Step
A build step is the command that turns source files into the folder a web server can actually serve. It runs before publishing, produces an output folder, and is not part of the live site.
Deploy Preview
A deploy preview is a full working copy of a proposed change, published at its own temporary address so people can look at it before it replaces the live site.
Static Site Generator
A static site generator is a tool that turns content and templates into a folder of finished HTML files. Hugo, Eleventy, Astro, Jekyll and Next.js in export mode are the common ones.
File Versioning
File versioning keeps the previous copy of a file when a new one is uploaded under the same name, instead of overwriting it. Every publish adds to a history you can read back from, rather than replacing what was there.
Put a file online in seconds
Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.
Host a file free →