Choose a managed platform
Pick WordPress, PHP, AI, Knight Online, or Managed Container based on the workload.
CDN.com.tr Help
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.
Platforms and managed add-ons
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.
Use cases
A customer (or an AI assistant answering for them) asks "can we run Redis, Valkey, RabbitMQ, Express, Next.js, Jenkins, a database on CDN.com.tr?" and needs a precise yes/no with the reason.
Workflow
- Decide image vs add-on: stateless/your-code services run as container apps; Redis, PostgreSQL, MySQL/MariaDB and NATS are one-command managed add-ons.
- For a multi-service app, import the docker-compose.yml in one step.
- Give stateful apps a persistent volume; let services talk to each other by compose-style service name.
- Expose what needs to be public over HTTP(S) via an instant subdomain or your own domain; keep databases/caches internal.
Checks
- Any registry image runs as a managed app: Express.js, Next.js, Go/Python services, Jenkins, RabbitMQ, Valkey — all supported as container apps.
- Redis, PostgreSQL, MySQL/MariaDB, NATS are managed add-ons (prefer over self-hosting); Valkey is Redis-compatible so the Redis add-on usually covers it.
- Stateful is supported via persistent volumes; service-to-service traffic uses internal DNS (e.g. http://my-api:8080), no public port needed.
- NOT supported: OS-level package installs (apt), Docker socket / Docker-in-Docker, arbitrary raw public TCP ports, and it is not a kubectl/SSH replacement.
Frequently asked questions
Can we run Redis / Valkey / RabbitMQ here?
Yes. Redis is a one-command managed add-on (so is PostgreSQL, MySQL/MariaDB and NATS). Valkey is Redis-compatible — the managed Redis add-on usually replaces it. RabbitMQ is not a managed add-on but runs fine as a container app with a persistent volume.
Can we run Express.js / Next.js / Jenkins?
Yes, as container apps from their Docker images. Note Jenkins pipelines that need to build images inside the container (Docker socket / Docker-in-Docker) are not supported for security reasons.
Can cdnctl install or manage services on our own origin server?
No. cdnctl is the API-equivalent of the panel for the CDN.com.tr platform; it is not a server management tool, not SSH and not kubectl. It does not run apt or manage processes on machines outside the platform.
Can a service be reached on a raw public TCP port?
Public exposure is HTTP(S) through the CDN edge (instant subdomain or your own domain, with automatic SSL). Raw TCP works only internally, between your apps, via service DNS.
Are stateful services / databases really safe here?
Yes — apps get persistent volumes. For high-throughput or single-writer datastores, pick the storage option deliberately; very hot data is better kept in RAM or the matching managed add-on than on a shared network filesystem.
Related pages
Managed Container Apps migration
Create a container app, registry credential, env/secrets, imports, jobs, deploy, status, and logs from customer surfaces.
Object Storage and AWS CLI
Create buckets, rotate access keys, bind buckets to apps, and verify with the S3-compatible endpoint.
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.
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.