Why Every Site I Build Runs in a Container

If you've spoken to anyone in tech in the last decade, you've probably heard the word "Docker" thrown around. For website owners it sounds technical and abstract — but it's quietly become the foundation of how modern websites are built and hosted. Worth a brief explanation, because it directly affects the reliability of your site.

What Docker actually is

Imagine your website as a meal. The site itself (the code, the content, the database) is the food. To cook the meal you need a kitchen — a specific oven, particular pots, the right ingredients in the cupboard. If the kitchen changes (different oven, different ingredients), the meal can come out wrong.

Docker is, in this analogy, the entire kitchen packed into a single takeaway box. The website plus everything it needs to run — exact PHP version, exact database version, every dependency — bundled together so it cooks the same way every time, no matter which oven (server) you put it in.

That's the whole idea. The technical name for the box is a "container".

Why this matters to you

The pitch sounds abstract, but the practical effects are real:

No more "it worked on the old server." When a host migrates your site or upgrades hardware, the container moves with it. Same versions, same behaviour, no surprise breakages.
Faster recovery from outages. If a server fails, the container can be brought up on a different machine in minutes rather than hours.
No conflict between sites. Each website lives in its own container, isolated from the others. A misbehaving plugin on site A can't take down site B.
Identical development and production. The site I build on my laptop runs in the exact same environment as the one your customers see. Bugs that only show up "on the live site" largely disappear.

Why I use it for everything

Every website I build runs in Docker — on my laptop during development, and on the server in production. That choice has real benefits for clients I won't meet for years:

Easy handover. If you ever need to move to a different developer, the entire site — code, database, configuration — comes with a single file describing the container. They can spin up an identical environment in minutes, no archaeology required.
No version lock-in. I'm not stuck running outdated software because some critical site needs an old PHP version. Each site has its own container with exactly what it needs, independent of everything else.
Reliable backups and rollbacks. Containers are immutable. If something goes wrong I revert to a known-good version with full confidence the previous behaviour is exactly restored.

What "Docker-optimised hosting" means

You'll see some hosts (including PHAS, the Australian host I use for client work) describe themselves as Docker-optimised or container-based. In plain English: they don't shove your website onto a shared server with hundreds of others fighting for resources. Each site gets its own properly-isolated container, which means consistent performance, stronger security, and faster recovery when things go wrong.

It's not the only way to run a fast, reliable website — but it's the most predictable. For small businesses where the site is genuinely making you money, predictability is the thing you want.

The bottom line

You don't need to understand Docker any more than you need to understand how electricity gets to your office. But it's worth knowing that the way websites are built and hosted has fundamentally changed over the last decade — and the businesses that benefit most are the ones whose developers are using modern tooling, not still copying files up via FTP and crossing their fingers.

Get in touch if you'd like an honest look at how your current site is hosted, or whether moving to a containerised setup would solve problems you've been running into.