Containers are for parity, not deployment

Technology

Docker's job on most projects is not shipping the application. It is making sure the Postgres, the Python version, and the headless browser a service depends on come up the same way on a laptop, in CI, and on a server. That is a reproducibility problem, not a hosting one.

Frontends deploy to Vercel, which builds them without a Dockerfile. Where an image earns its place is the work sitting behind them: a retrieval service, a scheduled job, a sandbox running code a model wrote. Those need a defined environment, so those get an image.

Monogram logo

Containers

Where an image earns its place

  1. Compose is the environment, not the product

    A service that needs Postgres with pgvector, a specific Python, and a headless browser gets those from a compose file instead of a setup document nobody rereads. Every machine and every CI runner starts from the same image, so a failure is about the code rather than the box.

  2. The image is the deploy only sometimes

    Cloud Run, ECS, and most GPU hosts take a container as the unit of deployment, so a Python retrieval service or a fine tuned model ships as an image. A Next.js frontend on Vercel does not, because the platform already builds and runs it. Match the packaging to the target.

  3. A Dockerfile is a thing you maintain

    Base image CVEs, arm64 laptops against amd64 runners, build cache that quietly goes stale: an image is infrastructure with its own upkeep. If your platform already builds and runs the app, adding one to the deploy path buys nothing. Docker appears in no case study on this site.