When Docker starts slowing delivery down.

Docker is easy to add and easy to forget. The Dockerfile was written three years ago, the image is 2 GB, and the CI build takes fifteen minutes because every commit reinstalls all dependencies. Every developer pays that waiting time many times a day.

Security reviews are the next trigger. A scan of the production image shows hundreds of known vulnerabilities, most of them from an outdated base image. A customer or an auditor wants a plan.

A platform change can force the issue: a move to Kubernetes, to ARM servers such as AWS Graviton, or to Apple Silicon laptops. Images built for one CPU type stop working on the other.

What our Docker engineers do in a normal sprint.

  • Faster builds Reordering Dockerfile layers so dependencies are cached, adding BuildKit cache mounts and sharing the build cache between CI runs.
  • Smaller images Using multi-stage builds to keep compilers and development tools out of the final image, on a slim or distroless base.
  • Hardening Running containers as a non-root user and scanning images with Trivy or Docker Scout in the pipeline. Build secrets go in through secret mounts, so they never land in a layer.
  • Base image updates Pinning base images by version or digest, and letting Renovate or Dependabot open a pull request when a patched one is released.
  • Multi-platform images Building for amd64 and arm64 with buildx, so the same tag runs on laptops, CI runners and Graviton servers.
  • Local environments Writing a Compose file with the app, database, cache and queue, plus health checks and file watching, so a new developer is running within minutes.

Docker is part of many roles we hire for, from backend developers to MLOps engineers, and the deep work belongs to DevOps. Companies that outsource DevOps engineers to us get someone who owns the images, the pipeline and the registry together. That engineer works only on your product, in a team managed from our Chiang Mai and Bangkok offices.

Docker habits that cause trouble later.

The latest tag is where most trouble starts. An image that pulls latest for its base builds differently from week to week, and a rollback may not bring back what ran before. Pin versions and update them on purpose.

Secrets baked into layers are worse. A token copied in during the build stays in the image history even if a later step deletes it. Anyone with pull access can read it. Build secrets and runtime injection keep them out.

Some teams treat a container like a small virtual machine, with several processes, data written inside it and logs kept in files. A container like that can't be replaced safely. One process per container, data in volumes or managed services and logs to standard output keep it disposable.

Docker questions buyers ask.

  • Do we need a Docker specialist or a DevOps engineer? A DevOps engineer. Docker is one tool in that job, next to CI/CD, cloud infrastructure and monitoring. If containers are where your problems are, say so, and we look for extra depth there during the search.
  • Do we need Kubernetes as well? Often not. A handful of services run well on a container service such as AWS ECS, Google Cloud Run or Azure Container Apps. Kubernetes pays off with many services, several teams or special scheduling needs, and it needs an engineer to look after it.
  • Does Docker Desktop need a paid licence? For larger companies, yes. Docker requires a paid subscription for Docker Desktop in companies with more than 250 employees or more than USD 10 million in annual revenue. Docker Engine on Linux servers is still free, and Podman or Colima are alternatives on laptops.

Tell us what you need Docker for.

A service delivery manager will reply with the specialists we'd suggest, the monthly capacity and what the first month looks like.

Loading the form…

We reply within one business day.