Docker engineering services
Docker ended the argument about why something worked locally and failed in production. Every project we ship is containerised, because the alternative is a server whose state nobody can reproduce.
Where we use Docker
Docker is part of the stack on these 2 services. Each page covers how we work, what you get and what it costs to start.
Docker in practice
Docker settled the question of why something worked on one machine and failed on another: the image contains the application and everything it depends on, and the image tested in staging is byte-for-byte the one running in production. Everything we ship is containerised, because the alternative is a server whose state nobody can reproduce.
The secondary benefit is onboarding. A compose file gives a new developer the whole stack with one command, instead of a setup page that went stale two hires ago. The Dockerfile also ends up being the most accurate documentation of what the application actually needs, because it is the version that has to work.
What we build with Docker
Images built in CI, tagged by commit, and promoted through environments rather than rebuilt for each one.
A compose file that gives a new developer the full stack on day one instead of a day of setup.
Wrapping older applications so they can be deployed on modern infrastructure without a rewrite.
Is Docker right for you?
Ask usA good fit when
- Any application going to production — this is the baseline
- Local development environments with several services
- CI, where builds must be reproducible
- Packaging legacy applications for modern infrastructure
Probably not when
- Static sites, which just need a CDN
- Very small teams on a managed platform that already builds from source
What we run alongside Docker
The rest of the setup, and why each piece is there. We keep this list short on purpose — every dependency is something someone has to maintain.
- Multi-stage builds
- Build tooling stays out of the final image, which is most of the size problem.
- Docker Compose
- The whole stack locally, one command, no setup document to maintain.
- Trivy or Grype
- Image vulnerability scanning in CI, before the image ships.
- Distroless or Alpine
- Minimal base images — less to patch and a smaller attack surface.
- BuildKit caching
- Faster builds in CI, which is where build time actually costs money.
Why Docker
Let’s talkIdentical everywhere
The image tested in staging is the image running in production — byte for byte.
Dependencies are explicit
The Dockerfile documents what the application actually needs, which is more than most wikis manage.
Onboarding gets short
A new developer runs one command instead of following a setup page that went stale months ago.
What we get called in to fix
Get a second opinionEnormous images
Multi-gigabyte images carrying the entire build toolchain into production.
Running as root
Containers running privileged with no user defined — an easy and common finding.
Secrets baked into layers
Credentials in the image, still recoverable from history even after being removed.
No health checks
Orchestrators unable to tell a hung container from a healthy one.
Docker or the alternative
The comparisons we are actually asked to make, answered the way we would answer them on a call.
Managed platforms are simpler until you need control. Docker gives portability and reproducibility that a platform’s build system does not.
Compose for development, every time. Local Kubernetes adds complexity that does not improve the local loop.
Alpine for size; Debian slim when musl-related issues would cost more than the megabytes save.
Docker works well with:
AWS
Azure
Google Cloud
Grafana
Kubernetes
Prometheus
Python
Redis
Terraform
Angular
AnsibleGot an idea? Let’s make it real.
Tell us the short version
This could be the first step towards a new and successful collaboration. A one-line idea and a finished spec are both fine — tell us the problem, the deadline you’re working to and what’s in your way.
Keep looking
Frequently asked questions
No. Plenty of products run happily on a container service or a single host. Kubernetes is for when orchestration is genuinely the problem.
Multi-stage builds, minimal base images and no build toolchain left in the final layer.
Usually yes. The work is normally in externalising state and configuration, not in the Dockerfile itself.
Usually. The work is normally externalising state, configuration and file storage — not the Dockerfile itself.
Injected at runtime from the platform’s secret store, never in the image and never in the repository.