On this page
What Docker deployment gives you
Docker packages an application with its runtime and dependencies into an image that runs the same way on a laptop, a staging server and production. That removes the familiar “it works on my machine” problem and makes moving between servers much simpler. Docker deployment is the work of building those images well and running them reliably on your servers.
Done carelessly, containers bring their own problems: huge images, data lost when a container is recreated, ports exposed to the internet by accident and nothing restarting after a crash. We set things up so those problems do not appear.
When Docker makes sense
- Several applications with different runtime versions need to share one server.
- A SaaS team wants staging and production to run identical builds.
- An agency hosts many small client apps and wants each isolated from the others.
- A self-hosted tool, such as an automation platform or analytics suite, ships as a Docker image.
- You plan to move providers later and want the application to be portable.
Docker is not always necessary. A single simple site may be easier to run natively, and we will say so.
What’s included
- Dockerfiles with appropriate base images, multi-stage builds and non-root users where practical.
- Docker Compose files defining services, networks, volumes and restart policies.
- Health checks so unhealthy containers are detected and restarted.
- Memory and CPU limits so one container cannot starve the rest.
- Persistent volumes for databases and uploads, included in backups.
- A reverse proxy in front, with internal services kept off public ports.
- Pinned image versions and a documented update procedure.
How we deliver it
- Review the application, its dependencies and how data is stored.
- Write and test the Dockerfiles locally, keeping images small and builds repeatable.
- Define the full stack in Compose, including proxy, database and background workers.
- Deploy to the server, confirm health checks, restarts after reboot and data persistence.
- Document how to update, roll back, view logs and restore data.
Tools we use
Most deployments use Docker and Docker Compose on an Ubuntu server, fronted by Nginx or Traefik with Let’s Encrypt certificates. Images can be stored in Docker Hub, GitHub Container Registry or your cloud provider’s registry. For larger systems with many services and a need for automatic scheduling across machines, Kubernetes or a managed container service on AWS, Google Cloud or Azure may be the right step, and we will explain when it is worth the extra complexity.
If you also want automated builds and releases, see Docker Deployment in our DevOps services, which covers registries and promoting images through environments.
What affects timeline and cost
Containerising one well-structured application is quick. Time grows with the number of services, legacy code that assumes a particular server layout, data migration and any orchestration requirements. Hosting costs depend on your provider and the resources the containers need.
Existing applications that write files to arbitrary locations, depend on specific host paths or need system services inside the container usually need a little refactoring first. We identify these early so the estimate reflects the real work rather than an optimistic guess.
Compose, managed containers or Kubernetes
Choosing how to run containers is one of the most important decisions in the project, because it sets how much complexity your team carries afterwards. We recommend based on what you run today and expect in the near future, not on trends.
| Approach | Good fit when | Trade-off |
|---|---|---|
| Docker Compose on one server | A handful of services and modest traffic | Simple to run; one server is a single point of failure |
| Compose on several servers behind a load balancer | You need redundancy without a cluster | More setup; deployments must be coordinated |
| Managed container service (AWS, Google Cloud, Azure) | You want scaling without running a cluster yourself | Tied more closely to one provider’s tooling |
| Kubernetes | Many services, several teams, frequent scaling | Powerful, but needs real expertise to operate well |
Most small and medium businesses we speak to are well served by the first or second option. Because everything is already containerised, moving up a level later is a manageable project rather than a rewrite, so there is no need to start with the most complex choice.
Common mistakes
- Using the latest tag everywhere, so a routine restart pulls an untested version.
- Storing database data inside the container instead of a volume, and losing it on recreate.
- Publishing database ports to the internet because Docker bypasses the host firewall by default.
- Running dozens of services in Kubernetes when a single Compose file would do.
Related: Reverse Proxy Setup and CI/CD Pipeline Setup. Explore Cloud & Server Management, the cloud and server guide, or contact us.
Frequently asked questions
Do I need Kubernetes?
Most small and medium applications do not. Docker Compose on one or two well-run servers is simpler and easier to maintain. Kubernetes becomes worthwhile when you run many services across several machines.
Will Docker slow my application down?
For typical web workloads the overhead is small. Performance issues usually come from resource limits, storage choices or the application itself, which we check.
Can you containerise an older PHP or Node.js app?
Usually, yes. Older apps sometimes need small changes, such as reading configuration from environment variables, which we identify early.
How are containers updated?
You get a documented procedure, or an automated pipeline if you prefer, that pulls a pinned new version, checks health and can roll back.
Where are Docker images stored?
In a container registry such as Docker Hub, GitHub Container Registry or your cloud provider’s registry. Private registries keep your images out of public view, and pinned tags make sure every server runs the same version.
Talk to us about docker deployment
Containerised applications that behave identically on every machine they run on.