From an image to a public URL, without running servers
Getting a single container onto the internet normally means provisioning a host, installing a container runtime, wiring a reverse proxy, obtaining a certificate, and opening firewall ports — a lot of undifferentiated work for one API. Container Apps collapses that: you give it an image and a port, and it returns a live, HTTPS-secured name.cdn.com.tr URL. There is no host to patch, no nginx to configure, and no certbot cron to babysit, because the edge and TLS are part of the platform.
Healthchecks and zero-downtime rollouts
A deploy that swaps containers the instant the process starts will drop requests while the app is still warming up. The platform uses your healthcheck path to decide readiness: on a new deploy it brings up the new container, waits for the healthcheck to pass, shifts traffic, and only then retires the old one. That means a bad image that never becomes healthy doesn't take the service down — the previous version keeps serving until the new one proves itself.
Environment and secrets done properly
Twelve-factor apps read their configuration from the environment, and containers are no different. Plain settings go in as environment variables; anything sensitive — database passwords, third-party API keys, signing secrets — goes in as a secret that is stored encrypted and shown only by key name, never by value, after it's saved. When you bind object storage or a managed database, their credentials are injected the same way, so nothing sensitive ends up baked into the image or printed in a build log.
Scaling and resource plans that match real load
You pick a resource plan (CPU and memory) per app and a replica count, so a low-traffic internal tool and a public API don't have to share the same footprint. Running multiple replicas also gives you resilience: if one container is restarting, the others keep serving. Because rollouts are health-gated, scaling up or deploying a new version doesn't create a moment where the app is unreachable.
Edge route, Auto SSL, and WAF in front of your API
Every exposed container app is reached through the cdn.com.tr edge, so the same protections your websites get apply to your APIs. Auto SSL provides and renews the certificate, the WAF filters malicious and scanner traffic before it hits your service, and you can cache safe GET responses at the edge to take read load off the container. Your origin container is never addressed directly by the public — it only receives traffic the edge forwards.
Panel or cdnctl, and it composes with your stack
Everything you can do in the panel — deploy, set env and secrets, scale, read logs, restart — is also available through the cdnctl command-line tool, so container operations fit into scripts and CI. Container Apps is also the target for Docker Compose Instant Deploy: a multi-service compose file becomes several container apps plus managed add-ons in one apply, which is the fastest way to lift an existing stack rather than recreating each service by hand.
How to deploy, step by step
Create a container app
In the panel open Container Apps and create an app from a prebuilt image, for example myorg/api:1.4 from Docker Hub or a private registry. Set the container port your service listens on so the platform knows where to send traffic.
Add a private registry credential (if needed)
If the image is private, add a registry username and access token under Container Apps → registry credentials once, so the platform can pull it on every deploy. Public images skip this step entirely.
Set environment, secrets, and healthcheck
Add plain configuration as environment variables and sensitive values — API keys, database passwords, tokens — as secrets, which are stored encrypted and never echoed back. Define a healthcheck path so the platform knows when a new container is actually ready to serve, not just started.
Deploy and expose
Deploy the app, then expose the web port to get a free name.cdn.com.tr URL with automatic HTTPS, or attach your own domain. Traffic now flows through the cdn.com.tr edge to your container, with SSL terminated at the edge.
Scale, watch logs, and roll out updates
Set replicas and a resource plan for the load you expect, stream logs from the panel to debug, and push a new image tag to trigger a zero-downtime rollout. Prefer the terminal? cdnctl performs the same deploy, scale, and log operations from your shell.
Example scenarios
A Node or Go API is deployed from an image, exposed on a domain with Auto SSL, and shielded by the WAF, with safe GET responses cached at the edge.
A single service runs with its own resource plan and secrets, scaled to a few replicas for resilience, without sharing a host with the rest of the stack.
A product team stands up a throwaway environment from an image tag on a name.cdn.com.tr URL, then tears it down when the review is done.
Frequently asked questions
Does Container Apps build my image from a Dockerfile?
No — it deploys prebuilt images. You build and push the image to a registry (Docker Hub or a private one) and give the platform the image reference and port. If you want push-to-deploy from source, pair it with GitHub Deploy, which handles the build step, or use Docker Compose Instant Deploy for a multi-service stack of prebuilt images.
How does a zero-downtime deploy actually work here?
On a new deploy the platform starts the new container, waits for your healthcheck path to report ready, then shifts traffic to it and retires the old container. If the new container never passes its healthcheck, traffic stays on the previous version, so a broken build doesn't take the service offline.
Are my secrets visible after I save them?
No. Secrets are stored encrypted and displayed only by key name once saved — the values are not echoed back in the panel, in logs, or in previews. That lets you rotate a secret from the panel without it leaking into a screen recording, a support session, or a build log.
Can my container reach a managed database or object storage?
Yes. You bind a managed database, Redis, or an object storage bucket to the app, and the connection details and access keys are injected as environment variables or secrets. The container reads them from its environment, so credentials never have to be baked into the image.
How do I run more than one instance, and why would I?
Set the replica count on the app. Multiple replicas give you resilience — if one is restarting or unhealthy, the others keep serving — and they let the app handle more concurrent traffic. Combined with health-gated rollouts, scaling up doesn't introduce a window where the service is unreachable.
Can I manage container apps from the command line and CI?
Yes. The cdnctl tool performs the same deploy, scale, log, restart, and configuration operations as the panel, so you can script container operations or run them from a CI pipeline instead of clicking through the UI. It's also how you preview and apply a Docker Compose import from the terminal.