What we build with it
Containers are how everything we write gets packaged. A backend service, a scheduled job, a build environment — each one is an image with its dependencies pinned inside it, so "works on my machine" stops being a category of bug.
The practical benefit shows up when someone new joins a project. Instead of a setup document that is six months out of date, there is a compose file: one command brings up the service, its database and its dependencies at the versions the project actually uses.
Where we have shipped it
All of our backend work is containerised, including the services behind our portfolio projects. This site is built and deployed as a container image too.
When we recommend it
For any service that will be deployed somewhere other than the machine it was written on — which is all of them. The cost is a Dockerfile; the return is a reproducible build and a deployment story that does not depend on server state.
Where we would push back is on containerising a local developer workflow that is already simple. If a project is a single binary with no dependencies, a container around the dev loop adds friction without adding much. Ship the image; do not necessarily develop inside it.
In production those images run on Kubernetes.
