Domains card
In the row of the hostname you want to move, pick where it should be served from: your own source or one of your apps. The rows you changed are marked; Discard selection puts them back. Nothing has changed yet.
CDN.com.tr Help
You choose where each of your hostnames is served from, in the Domains card of the Platforms tab: your own server, or one of the apps in your account. No hostname moves until you pick it and confirm; you undo the choice in the same card.
Platforms and managed add-ons
You choose where each of your hostnames is served from, in the Domains card of the Platforms tab: your own server, or one of the apps in your account. No hostname moves until you pick it and confirm; you undo the choice in the same card.
In the row of the hostname you want to move, pick where it should be served from: your own source or one of your apps. The rows you changed are marked; Discard selection puts them back. Nothing has changed yet.
Click Review changes. The window names each hostname with where it is served from now and after. It also says how many of your delivery rules will not apply while the hostname is on the app. When the app has a test address, the window links to it: open the app there and check it before you confirm.
The card follows the change: first The change is being published, then The change is live. This usually takes under a minute. If it cannot be published, the card says so and shows Publish again.
Your site is live on Pull CDN and you run an app in the same account. You want to serve one or more of your hostnames from that app, and be able to go back.
No. On an account served by Pull CDN or Push CDN, creating an app does not touch your hostnames. The app opens at its own test address. Only you move a hostname to an app, by picking it in the Domains card and confirming.
Usually within a minute of your confirmation. The card follows the change and says The change is live when it is. You can leave the page; it continues.
Until the change is live, visitors are served from where the hostname was. From the moment it is live, they are served from the new destination.
In the same card, pick the previous destination (your own server) in the hostname's row and confirm. Your delivery rules apply again as you left them. Keep your own server running so that you can go back.
They stay. While the hostname is served by an app, your rules for that hostname do not apply; the confirmation window says how many. When you send the hostname back, they apply again with nothing for you to do.
Nothing changes. Your hostnames keep being served from where they were, and the panel tells you it could not be done. This holds for all of them when you picked several at once.
The panel tells you which hostnames the app serves and asks you to confirm. If you do, those hostnames return to your account's own source.
Yes. Pick the other app in the row and confirm. The new app takes the hostname over, then the previous one lets go.
The same way: you choose the app for each hostname. On an account with a single app and no other content source, the hostname is attached to that app and you are told. With several apps, the hostname shows as Not assigned until you choose.
One change is applied to an account at a time. The second request is answered with a message asking you to try again in a few seconds.
Not while the content source is Push CDN: your hostnames are served from your Push CDN storage, and the card shows them without offering an app. To serve a hostname from an app, the account's content source has to be Pull CDN or Platforms.
Pick WordPress, PHP, AI, Knight Online, or Managed Container based on the workload.
Create a container app, registry credential, env/secrets, imports, jobs, deploy, status, and logs from customer surfaces.
Create buckets, rotate access keys, bind buckets to apps, and verify with the S3-compatible endpoint.
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.
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.
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.