Platform guide
Source Deploy: how a plain folder becomes a running app
The reference for cdnctl's folder-based deploy: architecture, cdnctl.yaml fields, limits, and the failures we have actually seen with their fixes.
Back to Platform HelpArchitecture: what happens after cdnctl deploy
No git repository and no container registry are involved on your side. The pipeline is:
- cdnctl packs the project folder into a tar.gz (up to 128 MB) and uploads it to the panel under your account.
- The panel issues a signed download URL valid for 30 minutes — the only way the build environment can fetch your source.
- An isolated build sandbox (Kaniko inside a gVisor-sandboxed pod) fetches the tarball, unpacks it, and builds the Dockerfile. Builds typically finish in about a minute.
- The image is pushed to your account's private registry space (registry.cdn.com.tr/<account>/<app>) — never to a shared or public registry.
- The app is created or updated, exposed on its subdomain with SSL, and rolled out. cdnctl waits and prints the live URL.
cdnctl.yaml: the fields that matter
cdnctl init writes this file; you edit it, cdnctl reads it on every deploy.
- name — the app name; also the subdomain seed on first deploy.
- port — the container port your server listens on (all interfaces, not localhost).
- healthcheck — HTTP path the platform probes; deploys wait for it to pass.
- method — auto, source, git or compose; source is the folder path described here.
- The manifest itself is excluded from cdnctl check scanning, so its own values never mute a warning about your code.
# minimal cdnctl.yaml
name: task-tracker
port: 3000
healthcheck: /health
method: source
Limits — the honest fine print
- Source tarball: 128 MB max. Node projects fit easily once node_modules is excluded (init writes the .dockerignore).
- Build time: about a minute for typical Node/Python apps; heavy native builds take longer.
- The Dockerfile template covers Node, Python, PHP and static sites; anything else needs a hand-written Dockerfile (which deploy uses as-is).
- Payment stays in the panel: if the account has no platform package, deploy stops with the purchase link and cdnctl init --wait resumes after payment.
Troubleshooting: failures we have actually hit
Each row is a real failure from live runs, with the fix that worked.
- Container crashloops with ERR_DLOPEN_FAILED right after deploy — the image contains node_modules copied from your machine (native modules built for the wrong platform). Fix: add node_modules to .dockerignore and let npm install run inside the build. cdnctl check flags this before upload.
- Build failed on the first deploy — read the build log that cdnctl deploy prints; the most common cause besides node_modules is a dependency present locally but missing from package.json/requirements.
- App shows stopped after a create — run cdnctl deploy again (0.18.0+ triggers the rollout itself; older builds needed an explicit deploy).
- Site unreachable although the build succeeded — the server binds 127.0.0.1 or a port different from cdnctl.yaml. Bind 0.0.0.0 and the declared port; check catches the localhost bind.
- Healthcheck never passes — the path returns non-200 or the app needs longer to boot; verify the path locally first.
The commands, end to end
cdnctl init # detect project, write cdnctl.yaml + Dockerfile
cdnctl check # local pre-flight: errors block, warnings advise
cdnctl deploy # pack → upload → build → live URL
cdnctl container apps logs --app <app_uuid> --tail 100 # runtime logs
cdnctl deploy-token create --name "agent" # restricted token for AI agents