# Ship an AI-built app in 90 seconds: from git URL to live > A complete walkthrough of the first deploy: what detection reads, what the build actually does, where the ninety seconds go, and what to do when the detection guesses wrong. A complete walkthrough of the first deploy: what detection reads, what the build actually does, where the ninety seconds go, and what to do when the detection guesses wrong. 22 Jul 2026 · 4 min read · cmdz You have a repository. Claude Code wrote most of it. It runs on your machine. Now it has to run somewhere a stranger can reach it, with a database, with HTTPS, and without you learning what a Kubernetes manifest is. Here is exactly what happens, with the numbers. ## The command ```bash npx @cmdz/cli deploy ``` That is the whole thing. No `init`, no wizard, no YAML. If you would rather not install anything, connect the repository in the portal or tell your agent to do it — all three paths run the same code. ## Phase one: detection (about 2 seconds) The first thing that happens is that we read your source, not your instructions. Detection looks at the files that cannot lie: lockfiles, manifests, framework configuration. For a typical Next.js app it finds `package.json`, `pnpm-lock.yaml` and `next.config.mjs`, and concludes: Next.js 15, pnpm 9, Node 22, and — because there is a `schema.prisma` with a `postgresql` provider — that this app expects a Postgres database. That last inference matters more than it sounds, because it means the database gets provisioned **in parallel** with the build rather than after it. Provisioning a fresh Postgres cluster takes about fourteen seconds; the build takes about forty. Started in parallel, the database costs you nothing on the clock. The output of detection is a plan you can read: ``` detect next@15 · pnpm@9 · node 22 · prisma → postgres from package.json, pnpm-lock.yaml, next.config.mjs install pnpm install --frozen-lockfile build pnpm build start pnpm start ``` ## Phase two: build (about 38 seconds, cold) The plan goes into a sandboxed builder that turns it into an OCI image. On a first deploy this is the expensive part: dependencies download, the framework compiles, assets are produced. On a second deploy of the same app it is usually under fifteen seconds, because the dependency cache is warm. That is a bigger difference than it looks in a blog post — it is what turns "deploying is a thing I do at the end of the day" into "deploying is a thing I do while thinking". Build minutes cost 1.5 credits each, which is € 0.0015. A month of aggressive deploying costs less than a coffee. Queue waiting time does not count, on principle: you should not pay for our capacity planning. ## Phase three: release (about 22 seconds) The image starts in a Kata micro-VM. Not a container on a shared kernel — a real virtual machine with its own kernel, started by the same machinery that starts an ordinary pod. If you want the argument for why that matters when a model wrote the code, it is on [the security page](/security). Two replicas come up. A startup probe polls your app every two seconds until it answers. Only then does traffic move across. If it never answers, the previous version keeps serving and the deploy is marked failed with the reason — you do not get a half-deployed app and a mystery. ## Phase four: the bits that make it usable While the release happens, three things get wired up without you asking: - **`DATABASE_URL` is injected** into the app's environment. You never copy a connection string, and rotating the credential later does not need a redeploy. - **A certificate is issued** for the generated `*.cmdz.app` hostname. Attaching your own domain later reissues automatically. - **The deploy is recorded** with its image digest, so a rollback is a cutover to something that already built and already passed health checks. Seconds, not minutes. ## The total ``` queue 0.4s detect 2.1s build 38.2s scan 2.1s (parallel: provision postgres 14.0s) release 21.6s health 3.0s ──────────────── 92.1s ✓ https://linktree.cmdz.app ``` Ninety-two seconds. That is a cold first deploy of a small app with a database attached, which is roughly the hardest version of the easy case. ## When detection gets it wrong It will, sometimes. Monorepos, unusual build steps, a framework we have not seen. Two escape hatches, in order of preference. **A `cmdz.toml`.** Three lines usually does it, and explicit always beats implicit: ```toml [build] command = "pnpm turbo build --filter=web" [apps.web] start = "node apps/web/server.js" ``` **A Dockerfile.** If your repository has one, we use it and stay entirely out of the way. This is a first-class path, not a fallback for failures — plenty of people prefer it and they are not wrong. What will not happen is a silent guess. If nothing is recognised the build fails with `detect_failed`, naming what it looked for, what it found, and the `cmdz.toml` that would fix it. ## What it costs to have done this The app above, running all month with two replicas at 0.5 vCPU and 1 GB each, plus a small Postgres and daily backups, comes to roughly **€ 4.70 a month**, outbound traffic included at € 0.02 per GB. That last line is real but small; the same gigabytes at Vercel or Render cost 7.5× as much. And whatever happens next month — a launch, a bot, a loop your agent wrote at three in the morning — the number on the invoice cannot exceed the limit you set. That is [the whole product](/hard-limit), and the ninety seconds is just how you get to it. ## Set your limit and start. One click with a passkey, then you verify a payment method once to start your 14-day free trial (€ 10 of credit). After that it is prepaid pay-as-you-go — you only ever spend credit you have already bought, and no invoice ever arrives above the amount you set. - [Create account](https://app.cmdz.com/signup) - [Read the docs](https://docs.cmdz.com)