The real question is not price
Comparing a VPS invoice with a platform subscription answers the wrong question. Every option can run your container; what differs is how much of your attention it keeps asking for after the first deploy.
A container in production needs a domain and a certificate that renews itself, a way to restart when it crashes, somewhere for logs to go, a story for updating without downtime, and a database that is backed up. None of that is Docker's job. Whoever handles it is what you are actually choosing between — and the honest comparison prices your hours, not just the server.
Option 1 — a VPS you manage
Rent a virtual machine, install Docker, run your container. It is the most direct path and it genuinely works, with full root access and no abstraction between you and the machine.
Then the standing work begins: OS security updates, a reverse proxy in front, certificates that must renew, a restart policy for when the container dies at 4 a.m., disk that fills with logs and images nobody pruned, and backups you configure and — crucially — test. A deploy is your own script, and zero-downtime is something you build yourself.
Choose this when you want root, when you are learning how the pieces fit, or when you already run servers and one more is marginal. Avoid it when your product is the application and not the infrastructure underneath it.
Option 2 — Kubernetes
Kubernetes solves real problems: many services, rolling deploys, self-healing, autoscaling. If you are operating dozens of services across a team, it earns its complexity.
Below that scale the ratio inverts. You are maintaining a cluster, its upgrades, its ingress, its certificates and its YAML in order to run a handful of containers — and the cluster becomes a system that needs expertise of its own. Managed Kubernetes removes some of that, not the conceptual weight.
Choose it when your scale or your team already demands it. Do not choose it because it is what serious companies use; the seriousness is in matching the tool to the size of the problem.
Option 3 — a managed container platform
Here you hand over the container and the platform runs it: a domain with automatic HTTPS, restarts, logs, a healthcheck-gated rollout, and managed Postgres, Redis or S3-compatible storage attached when you need them.
On cdn.com.tr a deploy starts the new container, waits for your healthcheck path to report ready, then shifts traffic and retires the old one — so a broken build never takes the service offline, because traffic simply stays on the version that still works. The edge CDN sits in front of it with WAF and DDoS protection included.
The trade is real and worth stating: no root on the host, no OS-level package installs, and public access is HTTP(S) rather than arbitrary TCP ports. If your application needs something the platform does not expose, a VPS is the honest answer.
Three ways in, depending on what you have
The right route depends on where your image comes from.
If you already build and push images to a registry, use Container Apps: give it the image reference and the port, and it deploys. Nothing else changes about your pipeline.
If you want push-to-deploy from source, use GitHub Deploy. It handles the build step for you — your Dockerfile is built in a sandboxed builder and pushed to our private registry, so no registry account of your own is needed. Push to your branch and the new version rolls out behind the healthcheck.
If your app is several services, use Docker Compose Instant Deploy. Services with a build: section are built from their Dockerfile; services that reference a public image: (databases, caches, queues) are wired in as managed add-ons or apps. Multi-stage builds, target: and build.args are honoured. Preview the plan before anything is created, then apply it.
Preview what a compose file would become, then apply it
# see the plan first — nothing is created
cdnctl container compose preview --account <uuid> --file docker-compose.yml
# apply it when the plan looks right
cdnctl container compose apply --account <uuid> --file docker-compose.ymlWhat to check before you commit
Whichever way you go, the questions worth asking are the same. How does a deploy roll out — does a failed build take the site down, or does traffic stay on the last good version? Where do logs go, and can you read them without SSH? What happens to your data: is the database managed and backed up, or is it a container on a disk you are responsible for? Can you get out — is your image portable, or have you been rewritten into something proprietary?
That last question is the one people skip and regret. A Docker image built from your own Dockerfile is portable by construction: it runs the same on a VPS, on Kubernetes and on a managed platform. Keeping it that way is what makes the choice reversible.
Frequently asked questions
Do I need to build the image myself?
Only if you want to. Container Apps deploys a prebuilt image you push to a registry. GitHub Deploy and Docker Compose Instant Deploy build from your Dockerfile in a sandboxed builder and push to our private registry, so you need no registry account.
Can I run a database in a container here?
You can, but for anything you care about use the managed Postgres or Redis add-ons instead — they are operated and backed up for you. A database in a plain container is a disk you are personally responsible for, which is the part that hurts later.
What if my app needs SSH or a custom system package?
Put system packages in your Dockerfile — that is exactly what images are for. If you need SSH into the host, OS-level installs at runtime or raw public TCP ports, the managed platform is not the right fit and a VPS is the honest answer.
Is a managed platform slower than my own server?
Not inherently, and it usually ends up faster in practice because the global edge caches in front of it. The container itself runs on the same kind of hardware; what you lose is root access, not speed.