Cloud & DevOps
Deploying Cleanly When You Don't Control the Server
Not every project ships to Kubernetes. Shared hosting has real constraints — and a repeatable deploy is still achievable within them.
A lot of published advice assumes you own the platform: container orchestration, blue-green cutovers, immutable infrastructure. Plenty of real projects deploy to shared hosting with a control panel and a restart file, and the advice does not survive contact with that.
The stale artefact problem
The constraint that catches teams out is stale artefacts. Modern build tools emit content-hashed filenames, so every build produces new chunk names. Unzip a new build over an old one and both generations coexist on disk — the server sends fresh HTML referencing fresh hashes, while stale files linger and requests for anything the HTML no longer mentions fail. The site is broken in a way that looks random.
Clean deploys, every time
The fix is unglamorous: deploys must be clean. Remove the previous build directory before extracting the new one, rather than merging into it. Once that is written down as a step instead of assumed, an entire category of intermittent production failure disappears.
One command, one artefact
The broader principle is that a deploy should be one command producing one artefact, whatever the target. If assembling a release depends on somebody remembering the order of operations, it will eventually be assembled wrong — usually late in the day, usually under pressure.
A deploy process that relies on memory is a deploy process that fails on the day you are busiest.
