Loading...

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 Help

Architecture: 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