The everyday analogy: images and containers
Think of a shipping container. Whatever you put inside, it has a standard shape, so any ship, truck or crane can carry it without caring about the contents. A Docker container does the same for software: it wraps your application and its dependencies in a standard package, so any compatible system can run it identically — no "it works on my machine" surprises.
Two terms cause most of the confusion. An "image" is the blueprint — a frozen snapshot of your app and its environment. A "container" is a live, running instance created from that image. You can start many containers from one image, just as you can open many copies of a document from one template. Images are usually stored in a "registry" (like Docker Hub or a private one) and pulled when needed.
Compose files and how much Docker you actually need
Real applications are rarely one piece — you might have a web app, a background worker, a database and a cache. A docker-compose.yml file lists all of these "services" and how they connect, so the whole stack can start together with one definition. On CDN.com.tr you can import a compose file and each service becomes a managed app, while databases and caches can become managed add-ons.
Often you need less than you expect. If you run WordPress or a PHP site, you need no Docker knowledge at all — those platforms are point-and-click. Docker only matters when you want to run a custom application. Even then, many apps already have a ready-made image you can use by name, or a docker-compose file you can import, without writing Docker yourself.
How it works on CDN.com.tr, and its honest limits
To run a custom app, you give us an image (for example, a public image like "nginx" or your own from a registry) or import a docker-compose file. The platform pulls the image, runs it, gives it a URL with automatic HTTPS, and keeps it healthy. You manage environment variables, scaling and restarts from the panel — no server administration, and no need to build images on the platform itself.
The platform runs your containers but is not a place to build images or run Docker inside Docker, and it does not expose raw public TCP ports (public access is HTTP(S); internal service-to-service traffic stays private). For most web apps, APIs, workers and tools this is exactly what you want; for a CI system that builds images, you would build elsewhere and deploy the result here.
When Docker helps you here
Deploy something like RabbitMQ or Jenkins by image name, with a persistent volume so its data survives restarts.
Build your image in your own pipeline, push it to a registry, and run it here with a URL and HTTPS.
Import a docker-compose.yml and get web, worker, database and cache running together in one step.
Frequently asked questions
Is Docker hard to learn?
The basics are simple: an image is a template, a container is a running copy. For using CDN.com.tr you mostly just provide an image name or a compose file — you rarely need to write Docker yourself.
Can I use the platform without Docker?
Yes. WordPress and PHP hosting require no Docker at all. Docker only comes into play for custom container apps.
Can I build my image on CDN.com.tr?
No — the platform runs images, it does not build them (no Docker-in-Docker). Build in your own pipeline or locally, push to a registry, then deploy here.