The Friday-night app problem
A company manager we know spent a Friday evening with an AI assistant and, by midnight, had a genuinely useful internal tool: task tracking shaped exactly the way his team works, because he knows the work better than any vendor does. It ran beautifully — on his laptop.
Monday's options were all bad. Ask IT for a server and wait weeks for a ticket to crawl through. Push the company's data onto a foreign hobby platform. Or rent a bare VPS and become responsible for TLS, backups, patching and firewalls overnight. The code was good. What was missing was a road.
Why the usual deployment paths don't fit
Every mainstream path assumes something this builder doesn't have. Git-based deploys assume a repository and a branch workflow. Image-based deploys assume a container registry and the Docker fluency to feed it. Both assume the person shipping is, at least part-time, a deployment engineer.
What the AI-assisted builder actually has is simpler: a folder with working code in it. So that is exactly what the road should start from — the folder. See Deploy from Git when you do have a repository; the two roads end at the same platform.
The folder is enough
Install one small CLI, run one command in the project directory, and cdnctl works out the rest: the language and framework, the port, whether a Dockerfile exists (it can generate one), and even which AI coding agents are set up in the project — because the agent that wrote the app is usually the one that will keep shipping it.
$ cdnctl init
Proje : gorev-takip (node/express, port 3000)
Agent : claude-code (claude on PATH), cursor
Paket : ✓ Large (max 5 app)
Karne : 2 HATA, 2 uyarı — ayrıntı: cdnctl check
Yazıldı : cdnctl.yaml, AGENTS.md
→ Önce `cdnctl check` hatalarını düzeltin (deploy sonrası site açılmaz).A report card before your code leaves the machine
AI-generated apps fail in production for a handful of very repeatable reasons, and every one of them is visible in the source before deploying. cdnctl check runs entirely on your machine — no code is uploaded — and it refuses to let a known-broken app ship. These four findings below are not hypothetical: they are the exact faults our own test app was written with, caught on the first run.
$ cdnctl check
[ERROR] bind-localhost (server.js:61)
The app binds to 127.0.0.1 — unreachable inside a container.
→ Bind to 0.0.0.0 (just drop the host argument).
[ERROR] secret-in-code (server.js:10)
A hard-coded secret (API key/token/password).
→ Move it to --secret KEY=VALUE; read it via process.env.
[WARNING] sqlite-single-pod
SQLite loses data on restart / multiple replicas.
→ Mount a persistent disk or switch to a managed database.
[WARNING] no-healthcheck
No /health route — the platform can’t tell your app is alive.One command to a live URL
After the fixes, deployment is a single command. Under the hood your source is archived, uploaded over TLS, built into a container image inside an isolated sandbox, pushed to your account's own private registry space, and started behind a real HTTPS subdomain — but none of that needs your attention. The first run takes about a minute; every later release is the same one command.
$ cdnctl deploy
→ archiving source (gorev-takip)
→ uploading (0.1 MB)
→ starting build (Kaniko, isolated sandbox)
build: running
build: success (41 s)
→ creating the app
→ assigning a subdomain
→ first deploy
→ waiting for the app to come up
✓ LIVE: https://ca…….cdn.com.trSecurity and durability are defaults, not chores
The parts that made the VPS route scary are the platform's job here. TLS is issued and renewed for you. Builds run sandboxed, and images live in a registry space that belongs to your account alone. A healthcheck lets the platform restart your app the moment it stops answering. And when the report card spots a file database, it points you at persistent disks and managed MySQL/PostgreSQL — so a pod restart never eats your data.
Your AI agent can run this whole flow itself
cdnctl init writes a deploy section into AGENTS.md (and CLAUDE.md when present), so the agent that built the app knows the exact commands on its next turn. Agents get machine-readable output with --json, an MCP server via cdnctl mcp, and — importantly — their own deploy-only token: it can upload, build and release, and it can NOT touch DNS, billing or the rest of your account. Your panel password never leaves you. Details live in the cdnctl help pages.
Which road is yours?
Three roads, one platform. If you keep code in a repository and want push-to-deploy, take Deploy from Git. If you already build images and run a compose file, see Docker hosting. If what you have is a working folder — the Friday-night situation — this road was built for you: install cdnctl, run init, run deploy, send the URL to your team.
Frequently asked questions
Do I need GitHub or any git hosting?
No. The source travels as an archive straight from your project folder; git never enters the flow. If you later adopt a repository, the git road is there and the app stays the same.
Do I need to know Docker?
No. If the project has no Dockerfile, cdnctl init can generate a sensible one from what it detects. The build itself runs on the platform, not on your machine.
Where does my code actually go?
The archive is uploaded over TLS to your account, built once inside an isolated sandbox, and the resulting image is stored in a private registry space that only your account uses. Nothing is shared, and nothing runs outside your namespace.
What does it cost?
Any plan that includes the container platform — all standard plans do. cdnctl tells you if your account is missing it and links the purchase page; payment finishes in the browser and cdnctl continues where it left off.
How do I ship an update?
Run cdnctl deploy again. The platform builds the new image and swaps it in; the old version keeps serving until the new one is up.