Container decision
Docker hosting: PaaS, VPS or serverless
A Dockerfile does not decide the host. Choose by who operates the machine, whether the process must stay running, where state lives, and which network and region constraints must pass.
Standing answer
For a conventional web service, start with a managed application platform when build, deploy, TLS, restarts, and logs should be the provider's job. Choose a VPS when root access and host control are requirements. Choose serverless containers only when idle and execution limits match the workload, and Kubernetes only when its scheduling boundary is genuinely needed.
Priced from the dataset
What each boundary costs for the same container
The choice above is about who operates what. This is what that choice costs, for one identical container workload, in every boundary the dataset can price completely.
Workload priced: One always-on instance at 2 vCPU and 4 GB, 100 GB egress. No disk, no database.
| Boundary | Lowest complete bill | Provider and plan | Providers priced | Checked |
|---|---|---|---|---|
| VPS | $4.25 | HostBrrEPYC-4GBrr | 6 providers1 more listed without a price | 2026-07-25 |
Each figure is the cheapest plan in that boundary whose every mandatory charge for this workload we could verify, read from the vendor's own page, most recently on 2026-07-25. It is not a recommendation: this dataset knows what a provider bills, not whether a plan runs your stack. Kubernetes carries no complete bill for this workload, so it is shown without a number rather than estimated. Compare every provider on your own workload.
Working comparison
Compare the options that fit this decision
| Workload | Start with | Verify before choosing |
|---|---|---|
| WordPress in Docker | Managed PaaS only when it supports durable state; otherwise a VPS | Database, persistent uploads, cron, outbound email, backups and patch ownership |
| Self-hosted workflow automation | Always-on container PaaS or a VPS | Webhook reachability, encryption key, database, queue workers, retention and upgrades |
| Developer API or backend | Managed PaaS for the deploy path; VPS when host control is required | Sleep, request timeout, ingress, build or CI, database, queues and the first paid month |
| Stateless web service | Managed PaaS | Always-on floor, egress, regions, health checks and rollback |
Decision test
What changes the answer
- 01Use a PaaS when build, deploy, TLS, restarts, and logs should be the provider boundary.
- 02Use a VPS when you need host-level control, predictable always-on compute, or a specific low-cost region.
- 03Use a serverless container when execution is intermittent and cold-start or duration limits fit.
- 04Use Kubernetes only when scheduling, isolation, rollout, or multi-service requirements justify a cluster boundary.
Shareable result receipt
Fixed for this page: the same formula, assumptions and sources every visitor sees.
For a conventional web service, start with a managed application platform when build, deploy, TLS, restarts, and logs should be the provider's job. Choose a VPS when root access and host control are requirements. Choose serverless containers only when idle and execution limits match the workload, and Kubernetes only when its scheduling boundary is genuinely needed.
Formula
Monthly infrastructure bill = compute + database + storage + egress + backups + mandatory support. Optional and separate, never ranked: operations hours × your own team rate, and transition cost ÷ amortization months.
Assumptions
- One production service
- A single primary region
- No negotiated contract
- Team time excluded from every figure shown
Explicit unknowns
- Workload-specific cold-start tolerance
- Incident response and recovery time
Sources and freshness
- Railway pricing retrieved 2026-07-25
- DigitalOcean Droplet pricing retrieved 2026-07-25