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

This is a judgment question. The strongest answers reason from concrete signals, not "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 app or team, packaging it with its full runtime environment directly fixes that.
• The application is part of a multi-service architecture. Several services with different runtime dependencies benefit from container isolation — 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 like AWS ECS/Fargate or Cloud Run, containerizing isn't optional — it's the basic unit those platforms operate on.
• You need portability across environments/clouds. A containerized application can move between infrastructure providers more easily than one tightly coupled to a specific host's manual setup.
• CI/CD pipeline consistency matters. Building and testing against the exact artifact that will run in production 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 problem. A small app that's never had environment-mismatch issues, running on infrastructure the team already manages well, may not gain much from the extra layer.
• A managed PaaS already solves the environment-consistency problem. Platforms like Heroku, or a cloud provider's managed hosting service, often already give you a consistent runtime without needing to author and maintain Dockerfiles.
• Serverless fits the workload better. For genuinely event-driven, sporadic workloads — a webhook handler, a scheduled batch job — a serverless function can be simpler than a containerized deployment, with no idle infrastructure cost.
• The team lacks container expertise, and the overhead isn't clearly justified yet. Docker has a real learning curve: image building, networking, volumes, security hardening. A team without that expertise pays a real tax adopting it before the problems it solves actually show up.

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, registry management, networking and storage concepts. Adopting containers just because they're the current industry default, without the underlying problems actually being present, is premature complexity.

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? What's the actual deployment target? If the answer points toward Kubernetes or another container-native platform, containerizing isn't really a separate decision. 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 specific reason before adding that layer, rather than defaulting to it as an industry-standard checkbox." This kind of grounded, criteria-driven answer shows real judgment, not reflexive adoption of a popular tool.