The problem: a working image is not a running service
Having an API build cleanly into a container image is the easy 20 percent; getting it to production is the other 80. Traditionally that means renting a VM, installing a runtime, configuring a reverse proxy, obtaining and renewing TLS certificates, opening the right ports, adding a process manager so the app restarts on crash, wiring up log collection, and standing guard against attackers who find the box within hours of it being online. Every one of those steps is undifferentiated infrastructure work that has nothing to do with your API's actual job, and each is a place to get security or reliability subtly wrong. Container Apps exists to collapse that whole checklist into a few fields.
How cdn.com.tr solves it: managed containers behind the edge
You give the platform an image, a port, and a healthcheck, and it runs the container, routes traffic to it through the edge, and keeps it alive. TLS is handled by Auto SSL, the public entry point is the edge route rather than the raw container, and the WAF filters malicious traffic before it reaches your service. Configuration comes in as environment variables and secrets injected at runtime, scaling is a replica count you set, and logs and status are surfaced in the panel. The result is that the only thing you are responsible for is your application image; the server, proxy, certificate, and firewall concerns are absorbed by the platform.
Healthchecks: the deploy safety net
The healthcheck is what turns a deploy from a hope into a controlled operation. When you push a new version, the platform starts the container and polls your health endpoint, and it only routes traffic to the new instance once that endpoint reports healthy. A build that crashes on boot, can't reach its database, or is missing a required secret fails the check and does not get put into rotation, so a bad deploy is caught at rollout instead of by your users. That is why the healthcheck should verify real readiness — dependencies reachable, config present — rather than just returning 200 unconditionally. A meaningful healthcheck is the difference between safe redeploys and silent outages.
Environment vs. secrets: config without leaks
APIs need configuration — database URLs, third-party keys, feature flags — and the wrong way to supply it is baking it into the image or committing it to the repository, where it lives forever in layers and history. The platform separates plain environment variables from secrets: non-sensitive settings go in as environment, while passwords, tokens, and API keys are stored as secrets and injected at runtime by key, never displayed back or written into your build. This means the same image can move between environments with different config, your credentials stay out of version control, and rotating a secret is a platform action rather than a rebuild-and-redeploy scramble.
Scaling, logs, and the operational loop
Once the API is live, running it is a matter of a few controls rather than server administration. You pick a resource plan and set how many replicas to run, scaling up for a launch or a traffic surge and back down afterward. Logs stream in the panel so you can trace a request, debug a 500, or confirm a deploy actually took, and status shows you whether the service is healthy and when it last restarted. Every redeploy runs through the same healthcheck gate, so shipping a new build is a repeatable, observable action — you push the image, watch the check pass, and confirm in logs, without ever SSHing into anything.
Wiring in storage and data
Most APIs need somewhere to keep state, and the service composes cleanly with the rest of the platform for that. You can bind an Object Storage bucket to the container as environment variables so it reads and writes media or documents directly, and you can connect a managed database or Redis so the service has persistence and caching without you operating those either. Because these are attached through the platform and delivered as injected config, the API stays a stateless image that can be scaled and redeployed freely while its data lives in managed services beside it.
How to set it up, step by step
Point at your image
In the panel create a Container App and reference your prebuilt image (for example myorg/api:1.4) from a public or private registry. For private images, add a registry credential once so the platform can pull it. Set the port your API listens on so the edge knows where to send traffic.
Define the healthcheck
Give the app a healthcheck path such as /health or /ready that returns 200 only when the service is genuinely able to serve. This is what the platform uses to decide whether a new deploy is healthy before it receives traffic, so make it check the things that actually matter, like database connectivity.
Set environment and secrets
Add non-sensitive config as environment variables and sensitive values — API keys, database passwords, tokens — as secrets, so they are injected at runtime instead of baked into the image or committed to your repo. Secret values are stored securely and referenced by key, not echoed back.
Deploy and watch the healthcheck
Trigger the deploy from the panel or with cdnctl. The container is started, the healthcheck is polled, and the service is only marked ready — and only put into rotation — once it passes, so a broken build does not silently take traffic.
Attach a domain with Auto SSL and WAF
Expose the service to get a free name.cdn.com.tr URL with automatic HTTPS, or attach your own domain and let Auto SSL issue the certificate. Enable the WAF so the API sits behind edge filtering, and the origin container is reachable only through that edge route.
Scale and observe
Adjust the resource plan and replica count for the load you expect, and use logs and status to watch deploys, restarts, and runtime behavior. Redeploys follow the same healthcheck-gated path, so pushing a new version is a routine, observable operation.
Example scenarios
A JSON API is published from its image behind a domain with Auto SSL and WAF, giving the frontend a stable, secured HTTPS endpoint without any server to maintain.
A webhook receiver, image processor, or auth service runs in isolation with its own scaling and secrets, deployed and redeployed independently of everything else.
A product team stands up a container from a tagged image to get a shareable HTTPS URL for a demo, then tears it down or redeploys as the build moves on.
Frequently asked questions
Does the platform build my image, or do I bring one?
You bring a prebuilt image from a registry. Container Apps runs and routes the image you provide; if it's private, you add a registry credential once so the platform can pull it during deploy.
What happens if my new deploy is broken?
It fails the healthcheck and is not put into rotation, so traffic keeps going to the working version. A container that crashes on boot or can't reach its dependencies is caught at rollout rather than serving errors to your users.
How do I keep API keys and database passwords out of my code?
Store them as secrets, which are injected into the container at runtime by key and never baked into the image or committed to your repo. Non-sensitive settings go in as plain environment variables, so the same image runs in different environments with different config.
Can my API reach a database or Object Storage bucket?
Yes. You can bind an Object Storage bucket to the container as environment variables and connect a managed database or Redis, so the service has storage, persistence, and caching while staying a stateless, redeployable image.
How do I handle a traffic spike?
Raise the replica count and, if needed, the resource plan for the app. Because traffic enters through the edge and the containers sit behind it, you scale the number of instances to match load and scale back down afterward.
Can I deploy from the command line instead of the panel?
Yes. cdnctl drives the same container operations from your terminal — deploy, redeploy, scale, and inspect — so you can script deployments or run them from CI while getting the same healthcheck-gated behavior as the panel.