How do you decide when to containerize an application versus deploying it another way?

This is a judgment question, and the strongest answers reason from concrete signals rather than treating "just use Docker" as a universal default.

Signals that point toward containerizing

• Environment consistency is a real, recurring pain point — if "works on my machine, breaks in CI/production" has actually been a problem for this application or team, packaging the application with its full runtime environment (see the fundamentals topic) directly addresses it.
• The application is part of a multi-service architecture — several services, each with different runtime dependencies, benefit from the isolation containers provide (see the fundamentals topic's isolation discussion). Two services needing different, incompatible library versions can coexist without conflict.
• You're targeting an orchestrator that expects containers — if the deployment target is Kubernetes, Swarm, or a container-native cloud service (AWS ECS/Fargate, Cloud Run), containerizing isn't really optional — it's the fundamental unit those platforms operate on.
• You need portability across environments/clouds — a containerized application can move between different infrastructure providers more readily than one tightly coupled to a specific host's manually-configured environment.
• CI/CD pipeline consistency — building and testing against the exact same artifact that will run in production (see the production topic's CI/CD question) is much easier when that artifact is a container image.

Signals that point toward a simpler alternative

• A single, simple application with no real multi-environment consistency problem — a small application that's never actually had environment-mismatch issues, running on infrastructure the team already manages comfortably, may not gain much from the added abstraction layer.
• A managed PaaS already handles the "environment consistency" problem for you — platforms like Heroku, or a cloud provider's managed application-hosting service, often already provide a consistent, managed runtime environment without requiring you to author and maintain Dockerfiles yourself.
• Serverless/function-as-a-service fits the workload better — for genuinely event-driven, sporadic workloads (a webhook handler, a scheduled batch job), a serverless function can be operationally simpler than maintaining a containerized deployment, with no idle infrastructure cost at all.
• The team lacks container/orchestration expertise, and the operational overhead isn't clearly justified yet — Docker itself has a real learning curve (image building, networking, volumes, security hardening — covered throughout this stack). A team without that expertise pays a genuine tax adopting it before the underlying problems it solves are actually present.

The honest tradeoff

Containers solve real problems (environment consistency, isolation, portability, a standard packaging format for orchestrators) but add real operational surface area (Dockerfile authoring and maintenance, image security/vulnerability management, registry management, networking/storage concepts) that isn't free. Adopting containers because they're the current industry default, without the underlying problems they solve actually being present for your specific situation, is a form of premature complexity. This is directly analogous to the same judgment call covered in the Kubernetes stack's "does this project need Kubernetes" question, just one layer earlier in the stack.

A strong closing framing

"I'd want to know: does this application have a real environment-consistency problem today? Is it part of a broader multi-service architecture? And what's the actual deployment target? If the answer points toward Kubernetes or another container-native platform, containerizing isn't really a separate decision at all. If it's a single simple service on infrastructure the team already manages well, with no real pain point Docker would solve, I'd want a more specific reason before adding that layer, rather than defaulting to it as an industry-standard checkbox." This kind of grounded, criteria-driven answer demonstrates real judgment rather than reflexive adoption of a popular tool.