Production Environment
Definition
Production is the copy that counts. Everything else — a local folder, a staging environment, a preview link — exists so that production can be changed with confidence. It is more than the files: it includes the domain and its DNS records, the certificate, the caching rules at the edge, any redirects, and the analytics that tell you what happened. A static production environment is unusually simple, which is its main virtue. There is no running application to crash, no database to fall behind, no process to restart at three in the morning; there are files being served, and the ways they can be wrong are countable. The discipline that goes with it is equally simple: nothing is edited directly in production, and every change arrives the same way, so that any change can be undone the same way.
Why It Matters
The moment people start making small fixes straight on the live site, the copy in version control stops matching what visitors see, and the next proper deployment silently reverts them. That is how a mysterious regression is born — someone corrects a phone number in production on Tuesday, a routine publish on Friday puts the old number back, and nobody connects the two events. Production is also where caching bites. A change can be correct in the files and still invisible for hours if a long Cache-Control lifetime is in force, so knowing that your change appeared is a separate question from knowing that you made it.
How It Works
Give production one entry route and use it every time: promote the tested build, do not re-upload from a laptop. Prefer a host that swaps the whole site at once, so that no visitor can ever land mid-update on a page whose stylesheet has not arrived. Keep the last known-good version one click away, because rolling back is the first move in almost any incident and it should not require thought. After each publish, do a short smoke test against the live address rather than the staging one — homepage, a deep page, an asset, and a hard refresh — since caching and the certificate only exist properly here. Restrict who can publish, keep a deployment log so that a change can be tied to a time, and treat any manual edit to production as an incident to be tidied up rather than a shortcut that worked.
Real-World Example
A trade body keeps its rulebook, forms and archive live at bexley-institute.99helpers.site on its own domain, roughly 90 files. All changes are built and checked on a separate staging address, then the same files are promoted. One afternoon a newly published index page loses its navigation. The fix is not a hunt through the markup: it is one click back to the previous version, which takes seconds, followed by an unhurried look at the build that produced it. Visitors that afternoon see the broken page for under two minutes.
Common Mistakes
- ✕Editing files directly on the live site — the fix survives until the next publish overwrites it and nobody remembers why the old text is back
- ✕Checking a change only on staging and assuming production matches, when the difference is often the certificate, the domain or the edge cache
- ✕Publishing without a way back, so the response to a bad change is a rushed forward fix made under pressure
- ✕Letting several people publish from their own machines, which makes the live site a mixture of whatever each of them last had locally
Related Terms
Staging Environment
A complete, private copy of a site where changes are checked before they go live. For a static site it is simply the same files published at a second address that the public does not know about.
Smoke Test
A quick check after publishing that the obvious things still work. It is not thorough by design — its job is to catch the catastrophic failure in two minutes, not to find every bug.
Deployment Log
The record of what was published, by whom and when, alongside the output of the build that produced it. It is the first thing to read when a site was fine yesterday and is not today.
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.
Atomic Deployment
An atomic deployment switches a site from the old version to the new one in a single step, so visitors never see a mixture of the two. Either every file is new, or every file is still the old one.
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 →