Deploy a Docker Container on the CDN and Serve It From the Edge

What "Docker on the CDN" means

A CDN in its classic form sits in front of a website you already run: the edge caches your static origin and speeds it up. That is Pull mode, and it is great when you have a server somewhere. But if what you have is a Docker image — a backend API, a web app, a worker — you would still need a machine to actually run that container. That is the gap the managed container platform fills.

On cdn.com.tr you deploy the Docker image itself. The platform runs your container as a managed container app and puts it behind the CDN edge, so the same image that runs on your laptop with docker run is now served on a real domain with automatic HTTPS, edge caching and a WAF in front — without you provisioning a VM, installing Docker, wiring TLS or standing up a reverse proxy. You bring an image and a port; the platform handles running it and serving it globally. This is what people mean by "Docker on a CDN" or "Docker hosting" done the managed way: the container is the origin, and the edge delivers it.

Option A — deploy from the panel (no CLI)

The no-code path runs entirely in the cdn.com.tr Management Panel. Under CDN Hosting / Platforms, choose Managed Container and create an app from your image. You point it at a registry image and tag (for example registry.example.com/acme/app:1.0.0), set the port your container listens on (say 8080), and add a health check path so the platform knows when the container is actually ready (an HTTP path like /health, a TCP check, or none). Add the custom domain you want it served on, and if the image lives in a private registry, attach the registry credentials you saved earlier.

Then hit Deploy. The platform pulls the image, starts the container, waits for the health check to pass, and brings it online behind the edge. From the app's Operations view you can watch the deployment progress, tail logs, see status and revisions, and restart or roll back — all without touching a terminal. This is the right path when you want to see everything visually or you are deploying a single container by hand.

Option B — the cdnctl CLI

cdnctl is the operator command-line tool for cdn.com.tr and it drives the same platform. Sign in once and pick your account so every command knows where to work: run cdnctl login --email you@example.com --password ... (or cdnctl configure --endpoint https://cdn.com.tr --token <token> if you use an API token), then cdnctl accounts use <account_uuid>. Before your first deploy, cdnctl container preflight --account <uuid> checks that the account is ready.

Create and deploy the container in two steps. First define it: cdnctl container apps create --account <uuid> --name mobile-backend --image registry.example.com/acme/app --tag 1.0.0 --port 8080 --healthcheck /health --healthcheck-type http --domain api.example.com (add --registry-credential <uuid> for a private image, and --persistent-mount-path /app/data --persistent-storage-gb 5 if it needs a persistent volume). Then ship it: cdnctl container apps deploy --account <uuid> --app <app_uuid>. To get an instant preview without setting up DNS, cdnctl container apps expose --account <uuid> --app <app_uuid> mints an immutable <uid>.cdn.com.tr URL you can hit right away.

Day-to-day operation is all here too: apps logs --tail 100 to tail output, apps status and apps wait --status running --timeout 300 to check readiness, apps restart, apps scale --replicas 0 to pause (or scale up), apps show to see the app and its revisions, apps rollback --revision <uuid> to go back to a known-good release, apps diagnose when something is off, and apps update ... --env-json '{"APP_URL":"https://api.example.com"}' to change configuration. For private images, create the credential once with cdnctl container registry-credentials create --account <uuid> --name docker --registry-url https://index.docker.io/v1/ --username <user> --password <token> and reference it when you create the app.

Multi-service stacks, add-ons, jobs and data

Real apps are rarely a single container. If you already describe your stack with docker-compose, you can deploy the whole thing: cdnctl container compose preview --account <uuid> --file docker-compose.yml shows what will be created, and cdnctl container compose apply --account <uuid> --file docker-compose.yml --yes deploys the multi-service stack. Your compose file becomes managed container apps on the platform.

For the pieces your app depends on, bind managed add-ons instead of running them yourself: cdnctl container addons enable-redis, enable-postgres, enable-database or enable-nats provision the service and inject its connection details into your app as environment variables (use --env-prefix to control their names). Background and scheduled work is covered by jobs: cdnctl container jobs create --account <uuid> --app <app_uuid> --name sync --schedule "*/30 * * * *" --method POST --path "/run" registers a cron-style job that calls your app on a schedule, and jobs run [--wait] triggers it on demand. And to seed state, cdnctl container imports database --file dump.sql.gz loads a SQL dump, while cdnctl container imports files --file data.tar.gz --target-path /app/data unpacks files into a persistent volume.

Serving through the CDN edge

The point of running your container here rather than on a bare VM is what sits in front of it. Once deployed, your app is reachable on the custom domain you attached, served through the CDN edge. TLS is automatic — you get HTTPS with no certificate to buy, install or renew — and cacheable responses are cached at the edge close to your visitors, so your container does less work and users get faster responses. A WAF sits in front to filter malicious traffic and absorb attacks before they reach your container.

You do not need a custom domain to start testing. cdnctl container apps expose (or the same action in the panel) gives you an immutable <uid>.cdn.com.tr URL that serves your running container immediately — ideal for a preview, a demo, or wiring a mobile client to a backend before DNS is ready. When you are ready for production, point your real domain at the app and it is served on that instead, with the same automatic HTTPS and edge protection.

Deploy from Git — CI/CD and zero-downtime promotes

For an ongoing project you usually do not want to run a deploy command by hand every time. Connect a repository in the panel and pushes can auto-deploy: when you push, the platform builds and redeploys automatically, so shipping a change is just git push. This is the CI/CD path for containers on the CDN.

To keep production safe, deploys flow through a staging → production pipeline. A push redeploys your Staging environment first, where you can check the new version on a preview URL; when it looks right, a single manual Promote instantly swaps that build into Production. Because the promote is an instant swap of an already-built, already-warmed release, production changes over with zero downtime — no rebuild, no cold start for your visitors. cdnctl fits the same flow from a CI pipeline: authenticate with a token, then create/deploy the app as a build step, so your existing GitHub or GitLab CI can drive deployments too.

What people run as Docker containers on the CDN