Cloud & DevOps
Docker
Containers that make our builds behave the same everywhere.
Docker is an open-source platform that packages an application and everything it needs into a container, a lightweight, self-contained unit that runs identically on any machine. HDC uses Docker to pin build tools, databases and services so a site behaves the same on a developer's laptop, in a preview environment and in production. That consistency removes a whole class of deployment surprises.
Where it shines
- Runs an app identically across dev, staging and production, no 'works on my machine'
- Packages code, runtime, libraries and config into one portable, versioned image
- Spins up databases and services locally without polluting your machine
- Far lighter and faster to start than a full virtual machine
- Reproducible builds make CI/CD predictable and onboarding quick
- Huge registry of ready-made images for almost any tool or service
Trade-offs to weigh
- Adds a layer of tooling that's overkill for a simple static site with no backend
- A learning curve around images, volumes and networking for newcomers
- Image sizes and resource use need care, or local development gets sluggish
What Docker is
Docker is an open-source platform, first released in 2013, for building and running software in containers. A container is a lightweight, self-contained package that bundles an application together with everything it needs to run, its code, runtime, system libraries and configuration, so it behaves the same way wherever it runs.
The key idea is portability. A traditional install depends on whatever happens to be on the host machine: the right language version, the right libraries, the right settings. Miss one and the app breaks. A Docker container carries all of that with it, so the same image runs identically on a developer’s laptop, a colleague’s machine, an automated test runner and a production server. Unlike a virtual machine, a container doesn’t emulate a whole operating system, it shares the host’s kernel, which makes it far lighter and quicker to start.
How HDC uses Docker
Docker isn’t on every project, most of our work is fast static sites that don’t need it. We reach for it when a build includes its own application, database or services that have to behave consistently. In practice that means:
- We containerise application runtimes, most often Node.js, so every developer on a project runs the exact same versions, eliminating environment drift.
- We run databases locally in containers, PostgreSQL, MySQL, giving each project the precise database version it needs without cluttering the machine, and a clean teardown afterwards.
- We use Docker images in automated checks on GitHub, so the environment our tests run in matches the one we develop in.
- We promote the same images we’ve tested towards production, so there’s no gap between “what passed” and “what shipped”.
Why we apply it
For clients, the benefit of Docker is reliability they never have to think about. Most deployment disasters come from subtle differences between environments, a database version here, a missing library there. Containers remove that variability by packaging everything together, so what we test is what goes live.
It also makes us faster and safer. New work spins up in minutes rather than a day of environment fiddling, and reproducible builds mean a problem can be diagnosed and fixed with confidence rather than guesswork. That consistency turns into fewer outages and quicker turnarounds on the applications our clients depend on.
How Docker fits our stack
Docker is plumbing, not a headline. On the projects that need it, it sits underneath the rest of the stack: it packages Node.js runtimes and the build tools a project uses, runs PostgreSQL or MySQL locally for parity with production, and provides the consistent environment our GitHub automated checks execute in. When a containerised service needs a home, it deploys to infrastructure like AWS. The result is that the application a client relies on behaves the same at every step from a developer’s keyboard to live traffic.
When Docker isn’t the right tool
We don’t add Docker for its own sake. A typical marketing or brochure site built on Astro and served from Cloudflare Pages has no backend to containerise, so Docker would only add tooling and overhead for no gain. Containers earn their place when a project has its own application, database or services that must run consistently across environments. For a static, content-first site, which is most of what trades and local businesses need, we keep things simple and skip it.
Worked example
A booking tool that behaves the same on every machine
Picture a trades client who needs a small booking app with its own database alongside their marketing site. We define the app's Node.js runtime and a PostgreSQL database as Docker containers, so every developer on the project runs the exact same versions, no one spends a morning chasing a bug that only exists because their laptop has a different database release. The same container images that pass our automated checks are the ones promoted towards production, so what we tested is what goes live. Fewer surprises means we ship faster and the client's tool stays reliable. (Illustrative, every build is scoped to your goals.)
Better together
How Docker fits with the rest of our stack
Docker: your questions answered
What is Docker in plain English?
Docker packages an application together with everything it needs to run, the code, the runtime, the libraries and the settings, into a single sealed unit called a container. That container then runs the same way on any computer, so software behaves consistently instead of breaking when it moves between machines.
Is Docker the same as a virtual machine?
No. A virtual machine emulates a whole computer including its own operating system, which is heavy and slow to start. A Docker container shares the host's operating system kernel and only packages the app and its dependencies, so it's far lighter, starts in seconds and uses fewer resources.
Does my marketing website need Docker?
Usually not. A fast static site built on Astro and hosted on Cloudflare Pages has no backend to containerise, so Docker adds no value there. We reach for Docker when a project includes its own application, database or services that need a consistent, reproducible environment.
Why does HDC use Docker?
Because consistency is what keeps deployments boring, in the best way. By packaging tools, databases and services in containers, we make sure an application behaves identically on a laptop, in our automated checks and in production. That removes 'works on my machine' problems and means what we test is exactly what your customers get.
Is Docker secure for client projects?
Containers add a useful layer of isolation between an app and its host, and pinning specific, vetted image versions makes builds reproducible and easier to audit. As with any tool, we keep base images current and patched, but the reproducibility Docker brings generally makes security review simpler, not harder.
Can Docker run databases locally?
Yes, and that's one of our most common uses. We run PostgreSQL, MySQL or other services in containers during development, so each project gets the exact database version it needs without installing anything permanently on the machine, and we can tear it all down cleanly afterwards.
Want Docker working for your business?
Tell us what you're trying to achieve, we'll show you, honestly, whether it's the right tool and how we'd apply it.
Enquire now