Docker is a way to package an application together with everything it needs to run — code, runtime, libraries and settings — into a single, portable unit called a container. The container behaves the same on your laptop, on a colleague's machine and on CDN.com.tr. You do not have to be a Docker expert to benefit: often you just point us at an existing image.
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.
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, 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.
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.
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.