Got a Docker Compose file? Your project goes live in seconds — one command on cdn.com.tr. See how

CDN.com.tr Help

Move a live Pull-CDN site to Platforms with no downtime

Run your origin services on cdn.com.tr Platforms while your site keeps serving via Pull CDN: enable apps alongside your current delivery, build and validate everything on ca-* subdomains, then cut the main domain over only when ready — fully reversible.

Platforms and managed add-ons

Move a live Pull-CDN site to Platforms with no downtime

Run your origin services on cdn.com.tr Platforms while your site keeps serving via Pull CDN: enable apps alongside your current delivery, build and validate everything on ca-* subdomains, then cut the main domain over only when ready — fully reversible.

Panel path

  1. Management Panel
  2. CDN Accounts
  3. Platforms tab
  4. Enable apps alongside current delivery
  5. Container Apps / Compose import
  6. Validate on ca-* subdomains
  7. Cut over main domain
  8. Decommission old origin

Use cases

A site is live on Pull CDN (its own origin) and the owner wants to move the whole stack (web, APIs, workers, Redis, queue, etc.) onto the platform without an outage.

Workflow

  1. Enable Managed Container Apps ALONGSIDE your current delivery — this does NOT change how your main domain is served (it stays on Pull CDN, live).
  2. Build your stack: import your docker-compose.yml (or create apps one by one). Redis/PostgreSQL/MySQL/NATS become managed add-ons; RabbitMQ/Valkey/Jenkins run as container apps with a persistent volume.
  3. Each app gets its own ca-*.cdn.com.tr subdomain (and an internal service-DNS name). Test the full stack on those URLs while the live site is untouched.
  4. When everything checks out, cut over: point your main domain to the front app. Your old origin stays up, so you can roll back instantly.

Checks

  • Enabling apps does not flip your content source or redeploy your main domain — the live Pull-CDN site is untouched.
  • Apps are reachable on ca-* subdomains and via internal service names before any cutover.
  • Cutover is a separate, deliberate step; the old origin remains a one-click rollback until you decommission it.
  • Map services correctly: Express/Next/backend → container apps; Redis → Redis add-on; database → Postgres/MySQL add-on; queue → NATS add-on or RabbitMQ app; Jenkins → app (no Docker-in-Docker).

Frequently asked questions

Will my live site go down while I set this up?

No. Enabling Managed Container Apps alongside Pull CDN is additive — it never changes your main-domain serving. Your site keeps serving from its current origin the whole time; only the explicit cutover step changes delivery.

How do I test before switching?

Every app is exposed on its own ca-*.cdn.com.tr subdomain (and reachable internally by service name). Validate the entire stack there. The main domain moves only at cutover.

Can I roll back the cutover?

Yes. Keep the old origin running; if anything is wrong after cutover, repoint the main domain back to it. Decommission the old origin only once you are confident.

Which of my services can move?

All of them as container images or compose services. Use managed add-ons for Redis/PostgreSQL/MySQL/NATS. RabbitMQ and Valkey run as container apps (Valkey is Redis-compatible, so the Redis add-on often replaces it). Jenkins runs as an app but cannot build images inside the container (no Docker socket / Docker-in-Docker).

Do I need a special plan?

Running several apps + endpoints needs an Enterprise plan. Check your entitlement before importing a large compose file.

Related pages

Object Storage and AWS CLI

Create buckets, rotate access keys, bind buckets to apps, and verify with the S3-compatible endpoint.

What you can run — capabilities and limits

A managed container platform (Kubernetes underneath), not a VM or shell server: you bring container images or a docker-compose.yml and the platform runs them, with managed Redis/PostgreSQL/MySQL/NATS add-ons, persistent volumes, internal service DNS, and HTTP(S) exposure through the CDN edge.

Persistent storage for a managed app

Give a container app a persistent volume so its data survives restarts and redeploys: enable storage, set the in-container mount path and size. One volume per app, mounted at one path, on CephFS.