Docker
Worth it once a team owns the containers, not before
We run Docker in three client systems: Elevent, TrialTriage and ZhoopZhoop. We also ship builds on Vercel and Supabase where a container adds nothing. Here is that line.
The short answer
Docker earns its place when a system needs a fixed runtime across environments or a background worker a serverless platform cannot host. A small team shipping a standard web app moves faster on Vercel or Supabase.
A container packages the runtime with the code, so the app that ran on a developer's laptop runs the same way on the server. That guarantee matters when a system has real-time connections, a job queue and a specific dependency version that has to match everywhere. It matters much less for a web app that reads and writes to a database and nothing else.
Docker fits Socket.IO clusters, Celery workers and any process that has to stay running rather than spin up per request. Vercel or Supabase fit a product where the framework's own deploy pipeline already covers the runtime, and nobody wants to own an image.
What decides this
4 things that decide this
- 01Docker wins when a runtime has to match exactly across a developer's machine, staging and production, which matters most for real-time and background-worker systems.
- 02Vercel and Supabase win on speed to a working product, because the deploy pipeline already exists and there is no image to build or push.
- 03Docker Compose is fine for local development on every build we run. In production it needs an orchestrator behind it before a second server joins.
- 04Image drift, not the container itself, is the failure we see most: a base image patched on one host and never rebuilt on another.
A packaged runtime, not a hosting platform
Docker builds an image: the code, the language runtime and every dependency, frozen at a specific version. A container is that image, running. Docker does not decide where the container runs. A team still has to choose a host, patch the base image and decide how containers talk to each other.
That is the trade a platform like Vercel removes. Push code, and the build, the runtime and the routing are handled for you. Docker hands you the same consistency, but the operational work that a platform absorbs becomes the team's job.
Where it holds up and where it does not
Strengths
- One image runs the same way on a laptop, a CI runner and production, which removes an entire class of "works on my machine" bugs before they reach a client.
- A Socket.IO cluster with a Redis adapter, or a Celery worker pool, needs a process that stays alive. Docker hosts that cleanly, where a serverless function cannot.
- Docker Compose gives a new engineer a full local stack, database and Redis included, running from one command on day one.
- The same image that passed CI is the one deployed, so a build cannot pass tests against one runtime and ship on another.
Trade-offs
- Compose is a development tool that keeps getting reached for in production. Without an orchestrator behind it, one host restarting takes the whole stack down.
- A base image left unpatched drifts from the one running elsewhere. If you inherit a Docker system someone else built, check this first.
- Someone has to own image builds, registry storage and rollout, and that ownership does not appear on its own. It has to be assigned.
- Multi-server clustering, the point where Compose stops being enough, is a real orchestration decision. Kubernetes is not worth reaching for on a small product team unless the workload justifies it.
- Single host, ComposeFine while there is one server
- Traffic growsA second server joins
- Sessions and sockets splitCompose has no view across hosts
- Manual patchworkSticky routing bolted on, not designed in
- Orchestration line crossedThe point to bring in a real scheduler, deliberately
We treat this line as a decision, not a default. Every one of our Docker builds names the point where Compose stops holding and what replaces it, before traffic forces the question.
What we use it for, and what each system taught us
Elevent runs real-time multiplayer trivia for corporate events, with Socket.IO clustered behind a Redis adapter so a game state stays consistent across servers. That clustering is the reason to containerize. A bare Node process has no clean way to share socket state across hosts. Docker plus Redis is what makes horizontal scaling possible at all.
TrialTriage matches oncology patients to clinical trials and runs Docker Compose in a HIPAA-aligned environment. The runtime has to be reproducible for an audit as much as for deployment. ZhoopZhoop runs AI voice and WhatsApp intake for a multi-branch auto shop, with Celery workers processing quote documents in the background behind Redis. Both needed a process that keeps running between requests, which a serverless platform would have killed mid-job.
- 01Reach for Docker when a background worker or a clustered real-time process needs to run continuously, not by default for every service.
- 02Pin and rebuild base images on a schedule. An image that was secure at build time drifts the moment a dependency ships a patch.
- 03Decide the orchestration line before traffic decides it for you. Compose on one host is honest; Compose pretending to be a cluster is not.
Systems running on this stack
Elevent
Real-time multiplayer trivia platform for corporate events and training.
Read the case study →
TrialTriage
AI clinical trial matching for oncology nurses and insurers.
Read the case study →
ZhoopZhoop
AI receptionist and parts procurement for a multi-branch auto repair business.
Read the case study →
What teams ask before committing
01Is Docker worth it for a small team?
What the system does decides this, not the team's size. A standard web app with a database moves faster on Vercel or Supabase, where the deploy pipeline is already built. Docker earns its place once a service needs a fixed runtime across environments or a background process that has to keep running.
02Is Docker Compose safe to run in production?
On a single server, yes, and you can run it that way for a long time. It stops being enough the moment a second server joins, because Compose has no built-in way to coordinate state or route traffic across hosts. Plan the orchestration step before growth forces it.
03Docker or a serverless platform for a new product?
A serverless platform, if the product is a standard web app with short-lived requests. Move to Docker once a specific workload outgrows what serverless functions allow, like a clustered real-time service or a background worker.
04What is the most common Docker mistake you see?
A base image built once and never rebuilt, so it drifts out of date while everyone assumes it is current. The fix is a rebuild schedule tied to dependency patches, not a one-time build at project kickoff. We treat image freshness as an ongoing job, not a setup step.
05When should we bring in Kubernetes instead of Compose?
When the workload genuinely needs multi-server scheduling, health checks and rolling deploys across a fleet, not because Compose feels outgrown. That is a real commitment with its own operational cost. We treat crossing it as a decision tied to load, not a default upgrade path.
Related
- Hire DevOps engineers →The role that owns image builds, patch schedules and the orchestration line.
- AWS, reviewed from production →Where containers usually end up running once they need real infrastructure.
- Vercel, reviewed from production →The platform that removes the need for a container on a standard web app.
- Software built for one business →The service that makes this call for a client.
