# cmdz > cmdz is hosting for people who build with AI. You buy credit upfront and can only ever spend what you have already paid — no invoice afterwards, no debt, no bill shock. What your agent builds runs here without configuration, in a real virtual machine, on hardware we own. cmdz is hosting for people who build with AI. The four claims below are the whole product, and every page on this site is an elaboration of one of them. - **The limit is a ceiling, not a warning.** You set an amount. Above that amount no invoice is produced — no back-charging, no overage, no exception. When usage reaches the limit the workloads pause and resume at the next billing period. - **What an AI builds runs without configuration.** Frameworks are detected from the source; no Dockerfile is required. Each app runs in its own Kata micro-VM with its own kernel, not a container on a shared kernel. - **An agent may do everything you may.** The platform is one REST API. The MCP server at https://mcp.cmdz.com/v1 exposes 47 tools over it, bounded by the same limit and the same audit trail as a human. Five operations are permanently blocked for agents: raising the limit, changing payment details, dissolving the organisation, transferring ownership, and managing members. - **Logging in takes one click and no password.** Passkeys only. Pricing is metered, 1000 credits = € 1.00 excluding VAT, and outbound traffic is not billed. The full price book is on https://www.cmdz.com/pricing. Every page on this site is available as clean Markdown by appending `.md` to its path. https://www.cmdz.com/llms-full.txt contains all of it inline in one fetch. ## Start here - [Hosting you pay for before you use it](https://www.cmdz.com/): You buy credit upfront and can only ever spend what you have already paid. No invoice afterwards, no debt, no bill shock. What your AI builds runs here without configuration, in a real virtual machine, on hardware we own. — Markdown: https://www.cmdz.com/index.md - [The hard limit](https://www.cmdz.com/hard-limit): You can only ever spend what you have already paid. Here is exactly how the prepaid balance works, what draws it down, what happens when it reaches zero, and what falls outside it. — Markdown: https://www.cmdz.com/hard-limit.md - [Pricing](https://www.cmdz.com/pricing): Prepaid credit, metered usage. One thousand credits is one euro, every usage item is listed with an amount — including outbound traffic at € 0.02 per GB — and you can only ever spend what you have already paid. — Markdown: https://www.cmdz.com/pricing.md - [How it works](https://www.cmdz.com/how-it-works): From a git URL to a live app in about ninety seconds: detection, build, release into a Kata micro-VM, health check and cutover. No Dockerfile required, and a rollback is one key. — Markdown: https://www.cmdz.com/how-it-works.md ## For agents, and for the people pointing them at us - [MCP server](https://www.cmdz.com/mcp): 47 tools over Model Context Protocol: create projects, deploy, scale, attach databases, connect domains, read logs, diagnose and explain costs. Five operations are permanently blocked for agents, including raising your limit. — Markdown: https://www.cmdz.com/mcp.md - [Build with an agent](https://www.cmdz.com/agents): For people who build with Claude Code, Cursor or Codex — and for the agents doing the building. The machine surface: llms.txt, raw Markdown per page, the OpenAPI spec, the MCP endpoint and the CLI. — Markdown: https://www.cmdz.com/agents.md ## Product - [Features](https://www.cmdz.com/features): Apps in any of twenty runtimes, managed Postgres and Valkey, object storage, vector search, domains and DNS in one place, preview environments, cron and queues, logs and metrics — all funded from one prepaid balance. — Markdown: https://www.cmdz.com/features.md - [Regions](https://www.cmdz.com/regions): Choose the region your app and data live in. Within a region we handle high availability; across regions you arrange your own redundancy with the building blocks we give you. — Markdown: https://www.cmdz.com/regions.md - [Security](https://www.cmdz.com/security): Real VM isolation with Kata micro-VMs, passkeys only with no password to steal, encryption at rest, an audit trail per action, and a data processing agreement you can download without a sales call. — Markdown: https://www.cmdz.com/security.md - [Our hardware](https://www.cmdz.com/hardware): We own the machines, in racks we manage, and that is why a spending ceiling can exist at all. Rocky Linux 10, k3s, Kata micro-VMs, encrypted disks, and one bootstrap command per node. — Markdown: https://www.cmdz.com/hardware.md ## Company - [About](https://www.cmdz.com/about): Who runs cmdz, how we make our money, what we deliberately do not do, and what happens to your data if we ever stop. — Markdown: https://www.cmdz.com/about.md - [Support](https://www.cmdz.com/support): Email and chat, answered by someone who can reach the servers — during business hours (CET), best effort outside them. No tiers, no ticket queue that routes you to a script. — Markdown: https://www.cmdz.com/support.md - [Contact](https://www.cmdz.com/contact): Email contact@cmdz.com or use the form. Your message goes to a mailbox a person reads, not into a CRM sequence. — Markdown: https://www.cmdz.com/contact.md - [Status](https://www.cmdz.com/status): Platform status, incident history and maintenance windows, hosted outside our own cluster so that it survives the outages it reports. — Markdown: https://www.cmdz.com/status.md - [Changelog](https://www.cmdz.com/changelog): What changed on the platform and when. Every entry says what it means for you, not just what we shipped. — Markdown: https://www.cmdz.com/changelog.md ## Writing - [Blog](https://www.cmdz.com/blog): Guides, product notes and engineering writing from the people who own the hardware: shipping AI-built apps, the hard limit, agents over MCP, regions and sovereignty. — Markdown: https://www.cmdz.com/blog.md - [Ship an AI-built app in 90 seconds: from git URL to live](https://www.cmdz.com/blog/ship-an-ai-built-app-in-90-seconds): 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. — Markdown: https://www.cmdz.com/blog/ship-an-ai-built-app-in-90-seconds.md - [The hard spending limit: why we cap instead of billing you more](https://www.cmdz.com/blog/the-hard-spending-limit): Every platform has a budget setting. Almost none of them stop the bill. Here is the mechanical difference, the balance sheet that makes it possible, and the two things that fall outside it. — Markdown: https://www.cmdz.com/blog/the-hard-spending-limit.md - [Let an agent run your infrastructure: MCP, scopes and safety](https://www.cmdz.com/blog/let-an-agent-run-your-infrastructure): Giving a model write access to your production platform sounds reckless. It is reckless — unless the blast radius is a number you set. Here is the full safety model, mechanism by mechanism. — Markdown: https://www.cmdz.com/blog/let-an-agent-run-your-infrastructure.md - [Connect Claude Code, Codex or Cursor to cmdz over MCP](https://www.cmdz.com/blog/connect-claude-code-codex-cursor-over-mcp): The configuration for each client, what the authorisation flow actually does, how to pick a profile, and how to tell whether it is working. — Markdown: https://www.cmdz.com/blog/connect-claude-code-codex-cursor-over-mcp.md - [Passwordless from day one: how passkeys work on cmdz](https://www.cmdz.com/blog/passwordless-from-day-one): No password, no username, no emailed code, no authenticator app. What that means in practice, what happens when you lose a device, and why we will not add a fallback. — Markdown: https://www.cmdz.com/blog/passwordless-from-day-one.md - [Deploy a Next.js + Postgres app without writing a Dockerfile](https://www.cmdz.com/blog/nextjs-postgres-without-a-dockerfile): The most common stack on this platform, end to end: detection, the database, migrations on release, environment variables, preview environments and what the whole thing costs. — Markdown: https://www.cmdz.com/blog/nextjs-postgres-without-a-dockerfile.md - [Deploy Laravel on cmdz: Octane, migrations and queues](https://www.cmdz.com/blog/deploy-laravel-octane-migrations-queues): A real Laravel deployment: the release command, queue workers as their own workload, the scheduler, Octane, storage on object storage, and where the horizontal-scaling surprises are. — Markdown: https://www.cmdz.com/blog/deploy-laravel-octane-migrations-queues.md - [Deploy FastAPI with a vector database for RAG](https://www.cmdz.com/blog/fastapi-with-a-vector-database-for-rag): A retrieval-augmented app end to end: FastAPI on Uvicorn, pgvector, where the embedding cost actually lands, and why the spending limit matters more for this shape of app than any other. — Markdown: https://www.cmdz.com/blog/fastapi-with-a-vector-database-for-rag.md - [Choosing a region: data residency and your own redundancy](https://www.cmdz.com/blog/choosing-a-region): What a region actually guarantees, what it does not, and how to run one app in two of them — including the honest limits of what we promise across regions. — Markdown: https://www.cmdz.com/blog/choosing-a-region.md - [Buy a domain and manage DNS in one place](https://www.cmdz.com/blog/buy-a-domain-and-manage-dns-in-one-place): Search, buy, attach and certify in one flow — plus why domains are the one thing charged outside your spending limit, and why we always show the renewal price. — Markdown: https://www.cmdz.com/blog/buy-a-domain-and-manage-dns-in-one-place.md - [Preview environments per pull request, explained](https://www.cmdz.com/blog/preview-environments-per-pull-request): What gets created, what is shared with production and what is not, how sleeping keeps twenty of them nearly free, and the two mistakes that make previews expensive. — Markdown: https://www.cmdz.com/blog/preview-environments-per-pull-request.md - [What counts toward your limit — and what does not](https://www.cmdz.com/blog/what-counts-toward-your-limit): The complete list, both columns, including the two things outside the ceiling and the reason for each. No "and more", no asterisks. — Markdown: https://www.cmdz.com/blog/what-counts-toward-your-limit.md - [cmdz vs a hyperscaler: cost predictability for AI builders](https://www.cmdz.com/blog/cmdz-vs-a-hyperscaler): Three concrete workloads priced against the published rates of Vercel, Railway, Render, Fly and Cloudflare — including the two profiles where they win. — Markdown: https://www.cmdz.com/blog/cmdz-vs-a-hyperscaler.md - [EU data, EU law: what sovereignty actually means for your stack](https://www.cmdz.com/blog/eu-data-eu-law): Beyond the region dropdown: where the control plane lives, where the logs and backups go, who the subprocessors are, and which questions to ask any provider claiming an EU region. — Markdown: https://www.cmdz.com/blog/eu-data-eu-law.md - [Scaling to zero and back: how cold starts work](https://www.cmdz.com/blog/scaling-to-zero-and-back): What actually happens between a request arriving at a sleeping app and it being served, where the milliseconds go, and when scale-to-zero is the wrong choice. — Markdown: https://www.cmdz.com/blog/scaling-to-zero-and-back.md - [Rollbacks in seconds: the 90-day deploy history](https://www.cmdz.com/blog/rollbacks-in-seconds): Why a rollback here is a cutover rather than a rebuild, what it does and deliberately does not undo, and how to make your migrations rollback-safe. — Markdown: https://www.cmdz.com/blog/rollbacks-in-seconds.md - [Metering explained: how usage becomes credits](https://www.cmdz.com/blog/metering-explained): The full chain from a 15-second sample to a line on your invoice: what we measure, how precise it is, which way the imprecision points, and why rounding happens exactly once. — Markdown: https://www.cmdz.com/blog/metering-explained.md - [Secrets and environment variables, done right](https://www.cmdz.com/blog/secrets-and-environment-variables): Where secrets live, why `env pull` writes names and never values, what an agent can and cannot see, and how to rotate a credential without a redeploy. — Markdown: https://www.cmdz.com/blog/secrets-and-environment-variables.md - [How we isolate customer workloads with Kata micro-VMs](https://www.cmdz.com/blog/how-we-isolate-workloads-with-kata): The difference between a namespace and a hypervisor as a security boundary, what it costs in memory and boot time, and why it matters more now that a model wrote the code. — Markdown: https://www.cmdz.com/blog/how-we-isolate-workloads-with-kata.md - [Building an app entirely by talking to an agent: an end-to-end walkthrough](https://www.cmdz.com/blog/building-an-app-entirely-by-talking-to-an-agent): A complete session from empty directory to a live app on a custom domain, without touching a dashboard — including the two moments the agent had to come back and ask. — Markdown: https://www.cmdz.com/blog/building-an-app-entirely-by-talking-to-an-agent.md ## Legal - [Terms and conditions](https://www.cmdz.com/terms): The agreement between you and us for the use of the cmdz hosting platform, including the articles on prepaid credit, its validity and the fact that it is not refundable. — Markdown: https://www.cmdz.com/terms.md - [Privacy policy](https://www.cmdz.com/privacy): What personal data we process for our own operations, on what basis, for how long, who the subprocessors are, and what rights you have. — Markdown: https://www.cmdz.com/privacy.md - [Data processing agreement](https://www.cmdz.com/dpa): The GDPR article 28 processing agreement, downloadable and readable here without a sales conversation. It forms an integral part of the agreement. — Markdown: https://www.cmdz.com/dpa.md - [Acceptable use policy](https://www.cmdz.com/aup): What you may and may not run on this platform, how we enforce it, and how to report abuse. In case of conflict between documents, the strictest provision protecting the network, its users or third parties prevails. — Markdown: https://www.cmdz.com/aup.md ## Machine surface - MCP endpoint (Streamable HTTP, protocol 2025-06-18): https://mcp.cmdz.com/v1 - Developer documentation: https://docs.cmdz.com - OpenAPI specification: https://docs.cmdz.com/openapi.json - REST API base: https://api.cmdz.com/v1 - CLI: `npx @cmdz/cli` - Status: https://status.cmdz.com - Connect an agent in one command: `claude mcp add --transport http cmdz https://mcp.cmdz.com/v1` ## Operator Binadit B.V., Seinhuiswachter 2, 3034 KH Rotterdam. KvK 80923216, VAT NL861852990B01. --- # Full contents --- # Build with an agent > For people who build with Claude Code, Cursor or Codex — and for the agents doing the building. The machine surface: llms.txt, raw Markdown per page, the OpenAPI spec, the MCP endpoint and the CLI. A growing share of the people using this platform did not type most of their code, and a growing share of the visitors to this page are not people at all. Both are first-class here, and this page is written for both. Read this page as Markdown: /agents.md · /llms.txt · https://mcp.cmdz.com/v1 ## What this actually looks like on a Tuesday ### Step 1 — You say what you want "Put this repository live with a Postgres database and my domain on it." Your agent already has the tools; it does not need you to open a dashboard, find a button or paste a connection string. ### Step 2 — It does the boring parts It creates the project, picks a region, provisions the database, injects the variables, deploys, waits for the health check, attaches the domain and waits for the certificate. Then it tells you what it cost and what that does to your monthly run rate. ### Step 3 — The limit is the supervisor Anything that would cross your ceiling fails before it starts, with an error that says so in words the agent can act on. You are not supervising a spend; you are reading a summary. ``` > deploy this repo to cmdz with postgres and put linktree.dev in front of it cmdz_create_project linktree · nl-rtm-1 cmdz_create_service postgres small · quoted € 2.26/mo cmdz_connect_service DATABASE_URL → web cmdz_deploy build 38s · release 22s cmdz_wait_for_operation healthy after 3s cmdz_add_domain linktree.dev · cert issued ✓ https://linktree.dev is live (1m 34s) run rate € 4.72/mo · limit € 20.00 · 24% used > now scale it to 4 replicas that would reserve more than the limit allows. I cannot raise your limit — you would need to. ``` ## The machine surface Everything on this site is available without rendering HTML. Nothing here requires JavaScript, a login or a scrape. ### /llms.txt and /llms-full.txt A structured index of the whole site with one line per page, and a second file with every page inlined so the entire site is one fetch. [Open /llms.txt](/llms.txt) ### Raw Markdown per page Append `.md` to any path — `/pricing.md`, `/hard-limit.md` — or send `Accept: text/markdown`. Same content as the HTML, generated from the same source, no navigation chrome. [This page as Markdown](/agents.md) ### OpenAPI and the REST API The contract is generated from the implementation, never written by hand, and CI fails if the two drift. Every MCP tool and every CLI command is one endpoint from it. [openapi.json](https://docs.cmdz.com/openapi.json) ### The MCP endpoint https://mcp.cmdz.com/v1 — Streamable HTTP, protocol 2025-06-18, OAuth 2.1 with PKCE, 47 tools in three profiles. [How to connect](/mcp#connect) ### The CLI `npx @cmdz/cli`. Every command takes `--json` and returns exactly the same JSON as the identically named MCP tool, so an agent without MCP support loses nothing. [CLI reference](https://docs.cmdz.com/cli) ### Structured data Organization, SoftwareApplication, Offer and FAQPage as JSON-LD on the pages where they apply, plus a sitemap that lists both the HTML and the Markdown variant of every page. [sitemap.xml](/sitemap.xml) ## We would like to be read by AI. Our `robots.txt` explicitly allows GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended and CCBot. That is a deliberate choice and the opposite of what a lot of sites are doing right now. The reasoning is simple: if a person asks a model where to host an AI-built app with a spending cap, we would rather the model had read our pricing page than guessed. Every claim on this site is checkable, every price is on a page with a number next to it, and where a competitor is better than us we say so — which is exactly the material a model needs in order to give an honest answer. If that answer sometimes sends someone to Railway or Cloudflare instead, that is a correct outcome and we can live with it. ``` $ curl -s https://www.cmdz.com/llms.txt # cmdz > Hosting with a ceiling on your invoice … ## Start here - [Home](…): … — Markdown: …/index.md - [The hard limit](…): … — Markdown: …/hard-limit.md ## Machine surface - MCP endpoint: https://mcp.cmdz.com/v1 - OpenAPI: https://docs.cmdz.com/openapi.json $ curl -s https://www.cmdz.com/llms-full.txt | wc -l every page, inlined ``` [Read robots.txt](/robots.txt) ## What we will not let an agent do to you These are enforced at the API. No scope grants them, no profile contains them, and no tool offers them — including for an agent acting as the owner of the organisation. ### Raise your spending limit Because the ceiling is only a promise if the thing spending against it cannot move it. ### Change your payment details or VAT profile Because redirecting the flow of money is the single most valuable action for an attacker who takes over an agent. ### Dissolve the organisation Because dissolving a legal relationship is an act of the legal entity, not of a tool call. ### Transfer ownership Because ownership is the root of every other permission on the account. ### Manage members Because adding a member is how a temporary compromise becomes a permanent one. ## Tell your agent to read this page. It can. Then tell it to deploy something — the ceiling is already holding. - [Create account](https://app.cmdz.com/signup) - [Connect over MCP](/mcp#connect) claude mcp add --transport http cmdz https://mcp.cmdz.com/v1 --- # Changelog > What changed on the platform and when. Every entry says what it means for you, not just what we shipped. Product changes, newest first. Price changes get their own line with a date and a reason, and never apply retroactively to a period you have already started. Also available as Markdown: /changelog.md ### 24 July 2026 — Regions, and the region picker - Frankfurt (`de-fra-1`) is available. Rotterdam remains the default. - Region is now a choice per environment rather than a platform-wide assumption. Your app, databases, volumes, backups and logs stay in it. - Cross-region read replicas and health-driven DNS shipped, so you can arrange your own redundancy. We still do not promise automatic multi-region failover. - The price book can now carry a per-region factor. You see the price for your region before you create anything. ### 18 July 2026 — MCP server: the build profile is now the default - The consent screen defaults to `build` (41 of 47 tools) instead of `read`, because for most people that is the profile that actually matches what they want an agent to do. - Every response now carries the agent's own daily budget alongside the spend cap, so a client can show both. - Error responses gained `next_steps`, written for the agent rather than for a log file. An agent that gets a useful refusal stops instead of retrying. - The emergency stop now propagates in under five seconds, measured rather than estimated. ### 9 July 2026 — Cost per endpoint - The usage screen can now break cost down per route, so "why is this suddenly expensive" has an answer rather than a theory. - The same data drives a cost diff between any two deployments, and `cmdz_explain_cost` exposes it to agents. - Available on every plan, including the free one. ### 1 July 2026 — Preview environments sleep on their own - Previews now scale to zero after inactivity and wake on the first request, so twenty open pull requests cost close to nothing. - Production apps can opt in to the same behaviour with a wake schedule, so the first visitor of the morning never pays the cold start. ### 20 June 2026 — Sub-limits per project - An organisation can now set a ceiling per project inside its overall limit. Agencies asked for this so that one client site cannot consume another client's room. - Sub-limits appear in the MCP envelope too, so an agent working in one project sees that project's headroom. ### 11 June 2026 — Domains and DNS in one flow - Search, buy, attach and certify a domain without leaving the app screen. - The renewal price is now shown next to the first-year price before you confirm, always. A cheap first year with an expensive renewal is a dark pattern and we are not doing it. - Zone versioning: a bad record edit is one click away from undone. ### 2 June 2026 — The limit got louder, on purpose - Warnings at 80% and 95% now go to email, the portal and — if connected — Slack or Discord, in euros rather than credits. - The limit bar is now present on every screen of the portal rather than only the dashboard. - Raising the limit takes effect immediately and restarts paused workloads within seconds instead of at the next reconcile. ## Follow along. Product changes here, incidents on the status page, and price changes in a log with an RSS feed. - [Status page](/status) - [Blog](/blog) --- # About > Who runs cmdz, how we make our money, what we deliberately do not do, and what happens to your data if we ever stop. cmdz is built and operated by a team that can reach the hardware. That is not a slogan; it is the constraint that produced almost every decision on this site. Binadit B.V. · Seinhuiswachter 2, 3034 KH Rotterdam · KvK 80923216 ## From hosting. That is the whole answer. You pay a monthly amount and metered usage, capped at your limit. We do not sell your data, we do not run advertising, we do not take a referral fee from a database vendor, and there is no marketplace where a partner bills you separately for something we introduced you to. That matters more than it sounds. A platform that makes its margin on egress has to want your traffic to grow faster than your revenue. A platform that makes its margin on a marketplace has to want you to buy add-ons. Our incentive is that you stay, which means our incentive is that your invoice does not surprise you. We are profitable at a size where a hundred customers matters. That is a real constraint and it shapes what we build — we cannot afford to serve everyone, so we chose who to serve and wrote it down. ``` hosting subscriptions ✓ metered usage under the cap ✓ domain names (cost + 25%) ✓ selling data ✗ advertising ✗ marketplace referral fees ✗ egress margin ✗ per-seat pricing ✗ ``` [What that means for the price](/pricing) ## Four things we are not A positioning without a boundary is a slogan. These are on this page so you can disqualify us quickly if one of them applies to you. ### We are not the cheapest Coolify on your own Hetzner box is cheaper than us, full stop. Cloudflare is cheaper than us at high request volume. We sell the time and the knowledge, not the servers, and if you have both then you should keep your money. ### We are not a global edge network We have a handful of regions and more on the roadmap. If your users are spread across three continents and latency is your product, we are not the right platform yet. ### We are not built for a compliance department No SOC 2 attestation, no procurement process, no enterprise tier. If your purchasing requires those, we would rather tell you on this page than in the third meeting. ### We are not an AI builder We do not write your app and we have no ambition to. We host what your AI builds, and we make the platform something your AI can operate. ## Questions you should ask any small host ### What if you go under? You get your data and we help you move. Everything here runs on standard technology — OCI images, PostgreSQL, S3-compatible storage, ordinary DNS — so there is no proprietary format holding you. The export function is published and works today, not as a promise for that scenario. We would rather you could always leave and chose not to. ### Who actually answers when something breaks? Someone who can reach the servers — a person who can look at your build log, your metrics and the node your workload is on. We answer during business hours (CET) and do our best outside them, with no bot tier in front of them. ### Are you going to get acquired and change the pricing? We cannot promise what a future owner would do, and anyone who does is guessing. What we can do is publish every price change with a date and a reason in a log with an RSS feed, never apply an increase retroactively, and keep the export function working — so if it ever happens, you see it and you can act. ### Why the Netherlands? Because that is where the company is, where the racks are, and where the legal relationship sits. It also happens to be a good answer to a GDPR question, but it is not a marketing position we adopted — it is just where we are. ## Ask us something. You will get an answer from a person who can reach the machines. - [Contact](/contact) - [Support model](/support) --- # Support > Email and chat, answered by someone who can reach the servers — during business hours (CET), best effort outside them. No tiers, no ticket queue that routes you to a script. Not a tier, not a queue that routes you to a script, and not an upsell. Support is included for everyone — trial and prepaid alike — because a platform you cannot get help with is not cheaper, it is worse. Answered by a person who can reach the servers · Business hours CET, best effort outside them ## Where to reach us, and what for ### Email contact@cmdz.com for anything. This is the main channel and the one we measure. ### In-portal chat For quick questions while you are working. Same people, shorter answers, and it carries the context of the project you have open. ### Incidents The status page is hosted outside our own cluster, because a status page that goes down with the outage is not a status page. [status.cmdz.com](/status) ### Security security@cmdz.com for vulnerability reports. Acknowledged within one working day. [Disclosure policy](/security) ### Abuse abuse@cmdz.com to report something running on our platform that should not be. [Acceptable use policy](/aup) ### Privacy privacy@cmdz.com for data subject requests and questions about the DPA. [Privacy policy](/privacy) ## A person, not a ticket queue. There is no service level agreement attached to our support — an SLA from a company our size is a credit note, not an outcome. What we commit to instead is plain: a first response from a human, during business hours (CET) and best effort outside them, with no bot in front of them. We would rather not publish a precise-looking average we cannot stand behind. What you will not get is a first response from a bot that asks you to clear your cache. What you will get is somebody who can look at your build log, your metrics and the node your workload is on. ``` answered by a person ✓ who can reach the servers ✓ first-response bot ✗ ticket tiers ✗ clear-your-cache reply ✗ ``` ## Stuck on something? Email is fastest, and there is no ticket form to fill in first. - [Email support](mailto:contact@cmdz.com) - [Read the docs](https://docs.cmdz.com) --- # Contact > Email contact@cmdz.com or use the form. Your message goes to a mailbox a person reads, not into a CRM sequence. One mailbox, read by people who work on the platform. No routing, no lead scoring, no drip campaign afterwards. contact@cmdz.com · Binadit B.V. · Seinhuiswachter 2, 3034 KH Rotterdam ## Write to us Prefer email? **contact@cmdz.com** reaches the same place. For a vulnerability report use **security@cmdz.com**; for abuse on the platform, **abuse@cmdz.com**; for privacy and data subject requests, **privacy@cmdz.com**. **Binadit B.V.** · Seinhuiswachter 2, 3034 KH Rotterdam · KvK 80923216 · VAT NL861852990B01 Contact form posts to https://forms.cmdz.com/contact. Or email contact@cmdz.com. --- # Status > Platform status, incident history and maintenance windows, hosted outside our own cluster so that it survives the outages it reports. A status page that goes down with the outage is not a status page. Ours runs outside our own infrastructure, so it can tell you the truth on the day it matters. https://status.cmdz.com · Per region · Incident history and post-mortems ## Per component, per region ### API and portal Availability and latency of the control plane. ### Deploy pipeline Build queue depth and release success rate. ### Managed services Databases, cache, object storage, per region. ### Ingress and DNS Edge, certificates and the authoritative nameservers. ## What we publish afterwards. Every incident that affected customers gets a written post-mortem: what happened, what the impact was, what the cause turned out to be, and what changed as a result. We publish them whether or not the cause reflects well on us, and we do not quietly stop publishing them in a bad quarter. You can subscribe to updates per region, so a Frankfurt customer is not paged about Rotterdam maintenance. ``` ● all systems operational 12 Jul nl-rtm-1 degraded build queue 42 min cause: builder cache volume full fix: headroom alarm at 65% 03 Jun all API latency p99 > 2 s 11 min cause: unindexed query on usage rollup fix: index + query budget in CI ``` [Open the status page](https://status.cmdz.com) --- # Features > Apps in any of twenty runtimes, managed Postgres and Valkey, object storage, vector search, domains and DNS in one place, preview environments, cron and queues, logs and metrics — all funded from one prepaid balance. Your app, its database, its storage, its domain and its certificates come from one place, funded from one prepaid balance. There is no marketplace partner sending you a second bill. One balance · No tiers, no seats · One API — for you and for your agent ## Push it. We work out what it is. Detection reads your lockfiles and your framework config and produces a build plan: runtime version, package manager, install and build commands, start command. You can see that plan, and you can override any part of it in a three-line `cmdz.toml`. Twenty runtimes are recognised out of the box, and anything unusual runs from a Dockerfile — a first-class path, not a fallback. Each app runs in its own Kata micro-VM with its own kernel. - **Node** — Next.js, Nuxt, SvelteKit, Astro, Remix, Express, NestJS, Bun, Deno - **PHP** — Laravel (including Octane), Symfony - **Python** — Django, FastAPI, Flask - **Ruby, Go, Rust, Elixir** — Rails, net/http, Axum, Phoenix - **Static** — any build that produces a directory of files - **Anything else** — your Dockerfile, unmodified ``` # Only what you want to override. Everything # else stays detected. [build] runtime_version = "22" command = "pnpm build" [apps.web] start = "node server.js" release = "pnpm prisma migrate deploy" region = "nl-rtm-1" [apps.worker] start = "node worker.js" type = "worker" ``` [How a deploy works](/how-it-works) ## Databases and storage we run ourselves Not resold, not a marketplace partner, not a second invoice from a company you have never heard of. Attaching one injects the connection variables into your app; you never copy a connection string. ### PostgreSQL High availability within the region, automatic failover, daily backups with point-in-time recovery, and read replicas — including in a second region if you want to arrange your own redundancy. - Daily backups included - Restoring costs nothing - Read-only SQL from the CLI and from an agent ### Valkey Redis-compatible cache, queue backend and session store. The obvious companion to almost every app on this platform, at a price you see before you create it. - Ephemeral by default — nothing on disk, and a restart or a node move empties it - Persistence is one switch: AOF and/or RDB on a volume, plus a daily snapshot - Turn it on before you use Valkey for a queue you cannot afford to lose ### Object storage S3-compatible buckets for uploads, assets and exports, with per-bucket credentials and an operation counter you can actually read. ### Vector search Postgres with vector indexes, for retrieval-augmented apps. Priced per GB of index per month, in the same table as everything else. ### Transactional email Outbound mail from your app with delivery tracking, priced per accepted message. Rejected messages cost nothing. ### Cron and queues Scheduled tasks and queue workers as first-class workload types, with their own logs, metrics and retry behaviour. ## Buy the name and point it, in one flow. Search a domain, see the price including the renewal price, buy it, and it is connected to your app with a certificate before you have opened a second tab. DNS is ours: authoritative nameservers, an editable zone with versioning, and templates for the records that people always forget. Domain names are the one thing charged outside your balance, and there is a reason: a registry charges us at the moment of purchase, and a paused workload should never be able to cost you a domain name. You pay at cost plus a fixed 25% margin, on a card, with the renewal price shown before you confirm. - **Renewal price shown up front**, not just the first-year price - **Unlimited domains per app**, at no per-domain charge - **Automatic certificates**, requested and renewed, wildcards included - **Health-driven DNS** across regions, if you want your own redundancy - **Zone versioning**, so a bad record edit is one click away from undone ``` $ cmdz domains search linktr.ee linktr.ee taken linktree.dev € 14.38/yr · renews € 14.38 linktree.app € 16.75/yr · renews € 16.75 $ cmdz domains buy linktree.dev --attach web € 14.38 now, on your card, outside your balance. renews at € 14.38 on 25 Jul 2027. confirm? [y/N] y ✓ registered · zone created · A/AAAA → web ✓ certificate issued · https://linktree.dev live ``` ## Reachable the moment it deploys. You do not have to think about IP addresses, certificates or load balancers. If you are wondering whether you need your own IP address: you almost certainly do not, and the reason is worth one paragraph. ### IPv6 is free and on by default Every app and every service gets IPv6 out of the box. There is nothing to enable, nothing to configure and nothing to pay. It does not appear on your invoice because it does not have a price. ### Shared IPv4 ingress is included Your app answers over IPv4 as well, through our shared ingress. One address serves thousands of sites: when a visitor arrives, we work out which app they want from the hostname they asked for and route it there. This is how every modern hosting platform works, and it is why the web has not run out of addresses. For a website or an API it is indistinguishable from having your own. ### HTTPS and custom domains, handled Point your domain at the shared ingress with a CNAME or an A record — we show you the exact record — and the certificate is issued and renewed automatically. Wildcards included, as many domains per app as you like, at no charge. ### Dedicated IPv4 — the exception, on request A small minority of workloads genuinely need a stable, exclusive address: a raw TCP or UDP service that cannot be routed by hostname, or a third party that will only talk to an IP on their allowlist. For those we offer a dedicated IPv4 at **€ 7.50 per month**, plus a possible one-time provisioning fee. It is a gated add-on — available on request, in limited quantity, and only where we have headroom — because IPv4 is genuinely scarce and expensive to source. It is deliberately not a checkbox at signup, so the pool stays available for the people who need it. [See it in the price book](/pricing) ## The parts you only appreciate later Everything below is included. None of it is a plan tier and none of it is an add-on. ### Preview environments One per pull request, each with its own URL and its own environment variables. They sleep when nobody visits and are cleaned up with the branch, so having twenty of them costs almost nothing. ### Logs and metrics 7 days of runtime logs and 90 days of build logs, searchable, and thirteen months of metrics. Your agent can read both, which is what makes a three-in-the-morning diagnosis possible without you learning a dashboard. ### Cost per endpoint Which route costs what, so "why is this suddenly expensive" has an answer rather than a theory. The same data drives the cost diff between two deployments. ### Sub-limits per project An agency can give every client their own ceiling inside one organisation, so no client site can eat another client's room. ### Teams and roles Owner, admin, developer and viewer, with no per-seat price. An agent token can never hold a role that manages members or transfers ownership. ### Export everything Your data, your database dumps, your objects and your configuration, exportable at any time — published because we would rather you never feel locked in than have you wonder. ## The whole list is on every account. There are no tiers and no feature gates — trial and paid accounts get the same platform and differ only in how much credit is on them. You start with € 10 for 14 days. - [Create account](https://app.cmdz.com/signup) - [See what it costs](/pricing) --- # The hard limit > You can only ever spend what you have already paid. Here is exactly how the prepaid balance works, what draws it down, what happens when it reaches zero, and what falls outside it. Most platforms let you set a budget and then email you when you pass it. Here the ceiling is money that is already ours to spend on your behalf — you paid it in advance, and nothing can take it below zero. That is the product, not a setting in a screen somewhere. Prepaid: no invoice afterwards, no debt · 14 days of read-only grace at zero ## How a ceiling can exist at all Everything we measure becomes credits, and a thousand credits is one euro. Every minute a job prices what ran in the last minute and draws it off your balance. Before anything expensive starts — a build, a new database, an extra replica — the platform reserves the credits it expects to need and refuses if the reservation does not fit. That is the whole trick, and it is deliberately boring: **the check happens before the spend, not after it.** A budget alarm that fires after the fact can only tell you what already happened. A reservation against money you have already paid simply does not let it happen. There are two ceilings and the lower one wins: your **balance**, which is absolute, and an optional **spend cap** you can set below it to bound a month. Neither can be crossed, and no agent can lift either. ``` scrape kubelet · cadvisor · traefik · minio rollup 15s samples → 60s grains price display-unit formula → credits book credit_ledger + spend_caps.used balance 20 000 credits (€ 20.00 prepaid) reserved 840 credits (build in flight) used 12 403 credits (€ 12.40) remaining 6 757 credits → 34% left ``` ## What happens as the balance runs down ### Step 1 — At 80% and 95%, you hear about it An email, a portal notification, and — if you have connected one — a message in Slack or Discord, in euros rather than in credits. Every MCP response an agent receives also carries the remaining balance, so an agent working on your behalf sees the brake as often as it acts. Auto-top-up, if you switched it on, buys more before this point. ### Step 2 — At zero, the workloads pause Your apps stop serving and visitors get a 503 with a Retry-After header, so crawlers treat it as temporary. Your databases stay readable for 14 days, your storage is mounted read-only, your backups keep running, your domains keep resolving. Nothing is deleted — it is paused, which is a reversible state. ### Step 3 — On a top-up, everything resumes Buy credit and the paused workloads come back within seconds. You can top up any time, and set auto-top-up so it never gets this far. An AI assistant can spend the balance but can never buy more, no matter how the request is phrased. ## What draws down your balance — and what does not Every usage item is here, including the small ones. There is no "and more". | Item | Draws down the balance? | Why | |---|---|---| | Compute and memory | yes | Metered per minute on what you allocate, not on what you happen to use. | | Storage and volumes | yes | On the allocated size, sampled every five minutes. | | Managed databases | yes | Per instance hour while running. Paused instances do not count. | | Backups | yes | Measured after compression, so you pay the smaller number. Restoring is free. | | Build minutes | yes | Only the build itself; queue waiting time does not count. | | Outbound traffic | yes | At € 0.02 per GB — 7.5× cheaper than Vercel and Render, but not free. It draws down credit you already bought, so it can be an expense but never a surprise. | | HTTPS certificates, extra domains on an app, extra team members | no | Included. No per-seat price, no per-domain price. | | Preview environments | yes | At the fraction of the month they are actually awake — they sleep on their own. | | Domain registrations and renewals | no | Deliberately outside the limit. See below. | | VAT | no | Credit is denominated excluding VAT. VAT is added on the invoice you get when you buy the credit, according to your tax status. | A domain registration is a purchase from a registry, not a metered resource: the registry charges us at the moment of purchase and the name is yours for a year. Putting it under the limit would mean a pause could cost you a domain name. It is charged separately on a card, at cost plus a fixed 25% margin, and the renewal price is shown before you confirm. ## What running out actually looks like A small Laravel app with a Postgres database and a handful of preview environments, on a € 20 top-up bought on the 1st. On the 27th the balance reached zero. The apps paused. Visitors got a 503 for four days, the database stayed readable, the backups kept running, and the domain kept resolving. The total paid that month is **the € 20.00 bought on the 1st**. There is no second invoice, no "usage above plan", and no message asking us to make an exception — there is nothing to ask about, because the money moved before the work did. - **Your data is never deleted** because a balance hit zero. Pausing is not termination. - **Topping up takes seconds** and restarts the workloads immediately. - **No invoice ever follows** — there is nothing left to bill. - **No debt is ever created**, so a failed payment is not a collection process. ## Where the competition is right A comparison that only says we win is a sales pitch the first critical reader turns around. So here is the part that is inconvenient for us. ### Railway already has a hard limit And a genuinely capable writing MCP server. They are the most dangerous competitor we have, and pretending otherwise would only make us look uninformed. Their minimum is $10 and hitting it takes workloads offline, which they themselves call a possibly destructive action. ### Cloudflare is cheaper at volume At fifteen million requests a month with short CPU times, Workers comes out around $8 and charges no egress at all. We will not reach that with a VM-based model. Our answer is not "we are cheaper" but "we run what you wrote, without you rewriting it into isolates". ### Netlify effectively caps too Their prepaid credit model bounds spend as long as auto-recharge is off, and it is easier for a layperson to understand than usage billing. It is not positioned as a limit, but it behaves like one. ## The ones people actually ask ### Can I ask you to let it run over just this once? There is nothing to ask for. Running over would mean us delivering something you have not paid for, which is the exact arrangement this model removes. Top up instead — that takes seconds and it is entirely in your hands. ### What if a bug in my code burns through the balance in a day? Then it pauses on that day and you are out one day of uptime instead of a four-figure invoice. That is the trade we are making on your behalf, and it is the one nearly everyone would choose in advance and nobody gets offered afterwards. The cost diagnosis tools will tell you which endpoint did it. ### What if an agent deploys in a loop? Every agent has a daily action budget and a daily deploy budget on top of your limit, and we detect anomalous patterns such as repeated identical deploys. You can revoke all agent access with one button, and revocation takes effect within five seconds. ### Does the balance apply per project or per organisation? The balance is per organisation. On top of it you can set a spend cap per project, so no client site can consume another client's room. Both bind; the lower one wins. ### Is there any way to end up with a charge I did not expect? Two, and both are things you buy rather than things you consume: domain registrations and renewals, charged on a card at the moment you confirm them, and auto-top-up if you switched it on — which charges your saved method when the balance falls below a threshold you set. Both are opt-in and both show the amount before they happen. Everything metered comes out of credit you already bought. ### What happens to my traffic while paused? Visitors get a 503 with a Retry-After header served by the edge, not a blank connection failure, so search engines treat it as temporary rather than gone. Your DNS keeps resolving and your certificates keep renewing, so nothing has to be rebuilt when it starts again. ## Two weeks on us, then only what you buy. Ten euros of credit, fourteen days, and no way for it to turn into an invoice afterwards. - [Start with € 10 of free credit](https://app.cmdz.com/signup) - [See the price book](/pricing) --- # Our hardware > We own the machines, in racks we manage, and that is why a spending ceiling can exist at all. Rocky Linux 10, k3s, Kata micro-VMs, encrypted disks, and one bootstrap command per node. Not resold capacity, not a subcontractor doing the management, not a region that gets consolidated next quarter. This page exists because the promise on the front page only makes sense if you believe this part. Own racks · Rocky Linux 10 · k3s · Kata · Encrypted at rest ## Why owning it is what makes the ceiling possible. A platform that buys from a hyperscaler pays per gigabyte transferred, per gigabyte stored and per CPU second. Their cost curve follows your usage exactly, so passing it on *is* the margin. For them a hard ceiling is not stubbornness, it is a loss. Our costs are mostly fixed: the machines are depreciated over years, the rack space is a monthly amount, the power is metered but predictable, and the transit is committed rather than per gigabyte. A customer who hits their ceiling costs us **capacity**, which we already paid for, rather than a purchase invoice we have to eat. That is the entire mechanism. It is not clever and it is not a business model innovation — it is just a different balance sheet, and it is the reason we can write "you can only ever spend what you have already paid" without an asterisk after it. ``` reseller cost model ├─ egress per GB → variable ├─ storage per GB → variable ├─ compute per sec → variable └─ a ceiling eats the margin cmdz cost model ├─ hardware depreciated → fixed ├─ rack + power monthly → fixed ├─ transit committed → fixed └─ a ceiling costs capacity, not cash ``` [How the ceiling works](/hard-limit) ## What is actually in the rack Boring, standard, and chosen so that nothing on this platform depends on a component we could not replace ourselves. ### Rocky Linux 10 Enterprise-grade, long-lived, and not owned by anyone whose licensing terms can change under us. Every node is identical and every node was installed the same way. ### k3s, driven from Postgres The desired state of every customer workload lives in our database, and an idempotent reconciler makes the cluster match it. We never read "the truth" out of the cluster — on drift, the database wins, without exception. ### Kata micro-VMs Every workload gets its own kernel. The isolation boundary is the hypervisor rather than a namespace, which is the point of the whole exercise. ### Replicated block storage Volumes are replicated across nodes within the region, with snapshots to object storage. Losing a disk is a maintenance ticket, not an incident. ### LUKS with network-bound unlock Full-disk encryption where the key is released by a service on the network at boot rather than stored on the machine. A disk that leaves the building is unreadable. ### One command per node A bare machine becomes a cluster node with a single bootstrap command carrying a one-time token that says which region and cluster it joins. There is no snowflake server and no manual step to forget. ## We order hardware before you notice a queue. Capacity is calculated per region against fixed thresholds — memory headroom, storage headroom, and enough margin to lose a node without losing the region. When a region crosses a threshold, the ordering advice says which region needs iron, and a region can be marked *limited* or *full* so no new environments land in it until it has been added. That is deliberately unglamorous. The alternative — running hot and hoping — is how a platform ends up either throttling customers or asking them to move region on short notice, and we would rather buy a machine. - **Thresholds per region**, not per fleet, so one busy region does not hide behind an empty one - **Room to lose a node** built into the threshold, not into a runbook - **Regions can be closed to new environments** rather than degraded - **Off-site backups** of the control plane, in a different region than the one they describe [Where the regions are](/regions) ## What owning the iron does not buy you. It does not make us cheaper than Cloudflare at high request volume — nothing VM-based will be. It does not give us a global edge network, and it does not give us a data center in every jurisdiction you might one day need. What it buys is a cost structure that can carry a ceiling, an isolation model we control end to end, and a support answer that comes from somebody who can physically reach the machine. If what you need is presence in twenty regions tomorrow, buy that from someone who has it. [Read the full comparison](/hard-limit#competition) ## The ceiling is downstream of the rack. Everything else on this site follows from the fact that we bought the machines. - [Create account](https://app.cmdz.com/signup) - [How the limit works](/hard-limit) --- # Hosting you pay for before you use it > You buy credit upfront and can only ever spend what you have already paid. No invoice afterwards, no debt, no bill shock. What your AI builds runs here without configuration, in a real virtual machine, on hardware we own. You buy credit upfront and your apps draw it down. There is no invoice afterwards, because there is nothing left to invoice. No overage, no back-charge, no debt. - [Start with € 10 of free credit](https://app.cmdz.com/signup) - [See the pricing](/pricing) 14 days of free credit to try it · No Dockerfile, no DevOps to learn · Your agent can ship it for you - **90 s** — From git URL to a live app, first deploy - **€ 0.00** — Invoices that can ever arrive after the fact - **€ 10** — Free credit to try it, for 14 days - **47** — MCP tools your agent can call ## Three things, and we mean all three literally. Every other decision on this platform follows from these. ### You pay first, so there is nothing to bill Most platforms meter your usage and collect afterwards. That caps the bill at best; it still means they delivered first and asked later, and a failed collection becomes a debt. Here your balance is money you already paid. Usage draws it down in real time, and when it reaches zero your apps pause. Nothing is deleted and no invoice follows, because there is nothing left to invoice. [Read exactly what happens at zero](/hard-limit) ### What your AI builds runs here You push your code and we work out how it should be built. No Dockerfile needed — allowed though. Every app runs in its own virtual machine with its own kernel, not in a container that shares a kernel with other customers. [How a deploy works](/how-it-works) ### Your agent can operate everything Claude Code, Cursor and Codex can create projects, deploy, scale, connect domains and explain costs over MCP. 47 tools. Buying more credit is not one of them. [See all 47 tools](/mcp) ## Three steps, and the third one is optional. ### Step 1 — Start on free credit You get € 10 of credit for 14 days — enough to build and run a real app. We verify a payment method first (€ 0.01, refunded automatically within 24 hours), which is what keeps the free credit from being farmed by throwaway accounts. ### Step 2 — Put your code on it Connect your repository or push with the CLI. We detect ourselves whether it is Next.js, Laravel, Django or something else. You add databases and storage with one command, at a price you see up front. ### Step 3 — Let it run, or let your agent run it From here you can do everything in the portal, or you tell Claude: "put this live on cmdz". The same API, the same rights, and the same balance — an agent can spend your credit but can never top it up. ``` $ npx @cmdz/cli deploy detecting … next@15 · pnpm · node 22 · postgres detected building ▸ nixpacks plan → image · 38s releasing ▸ kata micro-VM · nl-rtm-1 · 2 replicas ✓ live at https://linktree.cmdz.app 92s total balance € 7.60 left of € 20.00 · healthy ``` The first deploy of a small Next.js app is live within 90 seconds. Later deploys are faster, because the dependency cache is already warm. ## Why paying first is the stronger promise. A spending cap bounds the invoice. Prepaid removes the invoice. The difference shows up on the bad day: with a cap, the platform has already delivered and is asking you to settle up; here there is nothing to settle, because the money moved before the work did. That also means **no debt, ever**. A failed payment does not become a collection process, because there is nothing to collect — an unfunded balance simply stops buying compute. You can also set a spend cap *below* your balance if you want to bound a month. Both ceilings bind and the lower one wins. **An AI assistant can spend your credit but can never buy more**, however often you ask it to. [Read exactly what happens at zero](/hard-limit) ## What other platforms do when you go over From the providers' own documentation, fetched in July 2026. | Platform | What happens above your budget | Hard ceiling on the invoice | |---|---|---| | cmdz | There is no overage to have. Your balance is money you already paid; when it runs out the app pauses and your data stays readable for 14 days. | Yes — you can only spend what you prepaid | | Railway | Workloads go offline. Railway itself calls this a possibly destructive action. | Yes, minimum $10 | | Netlify | The site pauses until the next billing period, unless auto-recharge is on. | Effectively, via the credit balance | | Vercel | A notification, a webhook, or pausing production deployments if you turn that option on. The check runs every few minutes. Only on Pro. | no | | Render | Billed at the published rates. | no | | Fly.io | Billed. | no | | DigitalOcean | Billed. | no | | Cloudflare | Billed. But a ceiling on CPU time per invocation. | no | This data comes from the providers' own documentation, fetched in July 2026. Something no longer correct? Email us and we will adjust it, even if it is to our disadvantage. Railway has a real hard limit and the most capable writing MCP in the field — we say that here rather than letting someone else say it for us. [The full comparison, including where they beat us](/hard-limit#competition) ## Your AI assistant gets the keys. Not the wallet. cmdz has an MCP server with 47 tools. Claude Code, Claude Desktop, Cursor and Codex connect to it with one command. From that moment your assistant can create projects, deploy, scale, add databases, connect domains, read logs, diagnose problems, roll back and explain why something costs money. What it cannot do: buy credit, change your payment details, dissolve your organisation, transfer ownership or manage members. Those five things are permanently blocked, regardless of which rights you give. Every response the server returns contains your remaining balance. Not as an extra, but because **an agent reads the last response best**. ``` $ claude mcp add --transport http cmdz https://mcp.cmdz.com/v1 ✓ connected · profile: build · 41 of 47 tools > put the staging branch live and give it a database cmdz_create_service postgres · small · € 1.46/mo cmdz_connect_service DATABASE_URL injected cmdz_deploy staging → nl-ams-1 ✓ live at https://staging-linktree.cmdz.app balance € 6.14 left of € 20.00 · healthy ``` [See all 47 tools and the three profiles](/mcp) ## Choose your region. Arrange your own redundancy. Your app, your databases, your volumes, your backups and your logs live in the region you pick and do not leave it. Want to survive a data center going down? Run the same app in two regions and split the traffic — we give you the building blocks and you choose the level. | Region | Location | Status | Latency from Amsterdam | Data residency | |---|---|---|---|---| | nl-rtm-1 | Rotterdam, Netherlands | available | 1 ms | Netherlands / EEA | | nl-ams-1 | Amsterdam, Netherlands | available | 2 ms | Netherlands / EEA | | de-fra-1 | Frankfurt, Germany | available | 8 ms | Germany / EEA | | uk-lon-1 | London, United Kingdom | planned | 7 ms | United Kingdom | | us-nyc-1 | New York, United States | planned | 78 ms | United States | | sg-sin-1 | Singapore, Singapore | planned | 165 ms | Singapore | Within one region we handle high availability: multiple nodes, replicas and automatic failover. Across regions, redundancy is your choice — we do not promise seamless multi-region failover, because we would rather say that now than after an outage. ## What does your app cost? You pay for what you use, out of credit you bought first. One thousand credits is one euro, and every line — including outbound traffic — has a number next to it. The pricing calculator is interactive on the website. It takes visitors per month, app type, database size, number of preview environments and your limit, and returns an estimated monthly cost with a per-item breakdown, plus what happens if you hit your limit. The rates it uses are the price book on /pricing. ## What costs nothing extra No asterisk, no fair-use clause you find out about later. ### Extra team members No price per seat. Vercel charges $20 for an extra paid seat. ### HTTPS certificates Requested and renewed automatically, wildcards included. ### Preview environments As many as you have pull requests. They sleep on their own. ### Daily backups Including restoring them. 7 days of runtime logs, 90 days of build logs, thirteen months of metrics. ## Frequently asked questions ### What exactly happens when my credit runs out? Your apps pause. Visitors get a 503 with a Retry-After header, so crawlers treat it as temporary. Your databases stay readable for 14 days, your storage is mounted read-only, your backups keep running and nothing is deleted. Top up and everything comes back within seconds. ### Can I really never get a surprise invoice? Correct, and it is structural rather than a policy. You pay before you use, so at no point have we delivered something we have not been paid for. There is nothing to back-charge and nothing to collect — which also means we can never put you in debt. ### Why would a company restrict itself like this? Because we own our own hardware. Our costs are largely fixed, so a customer who runs out of credit costs us capacity we already paid for instead of a purchase invoice we have to eat. For a platform that buys capacity from a hyperscaler this would not work out. ### Is this cheaper than Vercel or Railway? Sometimes, and not always. At high traffic we are usually cheaper, largely on outbound traffic: we charge € 0.02 per GB where Vercel and Render charge € 0.15. At very little traffic their free tiers are cheaper, because free is hard to beat. What we always are, is predictable. ### What if my app goes viral? Then it burns through your balance and pauses. You get warnings as the balance falls, and you can top up in one action — or switch on auto-top-up beforehand, which buys credit before it is needed so the charge always precedes the usage. On the pricing page there is a calculator that shows at what traffic your balance runs out. ### Can an AI assistant drain my account? It can spend the credit you already bought, which is the point of giving it access — and that is the whole of the blast radius, because it cannot buy more. It also cannot change your payment details, dissolve your organisation, transfer ownership or manage members. Every agent has a daily action budget, we detect patterns such as deploy loops, and one button revokes all agent access within five seconds. ### Which frameworks are supported? We automatically detect, among others, Next.js, Nuxt, SvelteKit, Astro, Remix, Laravel, Symfony, Django, FastAPI, Flask, Rails, Express, NestJS, Go and Rust. If detection does not work, you use a Dockerfile and it runs anyway. ### Where is my data? In the region you choose, and it does not leave it. Our flagship regions are in the Netherlands, on hardware that is ours; Frankfurt is available and more are on the roadmap. If your users are in Asia and need low latency today, we are not yet the best choice — we would rather say that now than later. ### What about databases? We run PostgreSQL and Valkey ourselves, at a price you see up front. Postgres gets a daily backup with point-in-time recovery, included, and restoring costs nothing extra. Valkey is a cache by default — nothing on disk, emptied by a restart — and gets persistence plus a daily snapshot the moment you switch it on. You get no separate invoice from a third party. ### What if you stop? Then you get your data and we help you with the move. We run on standard technology — containers, PostgreSQL, S3-compatible storage — so there is no format you are locked into. We publish an export function for everything you have with us, even if you never leave. ### Do I need a payment method to start? Yes, and it is a verification rather than a charge: we take € 0.01 and refund it automatically within 24 hours. That is what keeps the free trial credit from being farmed by throwaway accounts, and it is why we can give real credit away rather than a crippled free tier. iDEAL, SEPA direct debit and credit card all work. ### How do I log in? With a passkey. No password, no email with a code, no authenticator app. One click or one fingerprint. We do not support passwords, not even if you ask for them. ### Do you have a free tier? Not a permanent one, and we would rather say so plainly. You get € 10 of credit for 14 days, which is enough to build and run a real app, and after that you buy credit like everyone else — from € 5. A forever-free tier funded by paying customers is how free tiers get worse over time; we would rather charge honestly and keep the platform predictable. Commercial use on trial credit is allowed. ### What is included at no extra charge? HTTPS certificates, preview environments, 7 days of runtime logs and 90 days of build logs, thirteen months of metrics, daily backups, extra domains and extra team members. Outbound traffic is not free but it is cheap: € 0.02 per GB, against € 0.15 at Vercel and Render. ### Do I get a human on the line? You get an answer from someone who can reach the servers — a person who can look at your build log, your metrics and the node your workload is on, not a bot that asks you to clear your cache. See the support page for how we work. ## Start on us for two weeks. Creating an account takes one click with a passkey — no password to think up. You get € 10 of credit for 14 days, and after that you only ever spend what you have already paid. - [Create account](https://app.cmdz.com/signup) - [Talk to a person](/contact) Questions? A human who can reach the servers will answer. --- # How it works > From a git URL to a live app in about ninety seconds: detection, build, release into a Kata micro-VM, health check and cutover. No Dockerfile required, and a rollback is one key. You never write a Dockerfile, a manifest or a pipeline unless you want to. The platform reads your source, works out what it is, builds it, and puts it in its own virtual machine behind HTTPS. Target: first deploy live in 90 s · Rollback in one key · Preview per pull request ## Six phases, and you see all of them ### Step 1 — Detect We read your repository: lockfiles, manifests, framework config. That produces a build plan — runtime version, package manager, install command, build command, start command — which you can see and override in a cmdz.toml if the detection got something wrong. ### Step 2 — Build A sandboxed builder turns the plan into an image, with a warm dependency cache from your previous build. Services your app needs — Postgres, Valkey, object storage — are provisioned in parallel, because that work does not depend on the image. ### Step 3 — Release The image starts in a Kata micro-VM with its own kernel. A startup probe polls until the app answers, and only then does traffic move over. If it never answers, the old version keeps serving and the deploy is marked failed. ``` $ cmdz deploy queue accepted 0.4s detect next@15 · pnpm@9 · node 22 · prisma → postgres from package.json, pnpm-lock.yaml, next.config.mjs build nixpacks plan → layers → image 38.2s cache hit: node_modules (412 MB) scan no critical CVEs 2.1s provision postgres-16 small · nl-rtm-1 14.0s (parallel) release kata micro-VM · 2 replicas · rolling 21.6s health startupProbe ok after 3.0s ✓ live https://linktree.cmdz.app 92.1s DATABASE_URL injected · rollback: cmdz rollback --to 41 ``` Ninety seconds is the target for a first deploy of a small Next.js app. A second deploy of the same app is usually well under thirty, because the dependency cache is already warm. ## What we recognise, and what happens when we do not Detection runs on your source, in this order. The first thing that matches wins, and you can always override it. ### A cmdz.toml, if you wrote one Explicit beats implicit, always. Anything you set in cmdz.toml — runtime version, install command, build command, start command, extra Nix packages, cache paths — overrides everything below it. ### A Dockerfile, if you have one If your repository has a Dockerfile we use it and stay out of the way. This is the escape hatch for anything unusual, and it is a first-class path rather than a fallback. ### Framework detection We recognise Next.js, Nuxt, SvelteKit, Astro, Remix, Laravel, Symfony, Django, FastAPI, Flask, Rails, Express, NestJS, Go, Rust and more, along with the package manager and the runtime version you pinned. ### Nothing recognised The build fails with a `detect_failed` error that names what it looked for and what it found, plus the three-line cmdz.toml that would fix it. It does not guess and it does not silently deploy something wrong. ## Your app gets a kernel, not a namespace. Most platforms in this category run customer code in containers that share one kernel. That is efficient and it is fine right up until a kernel escape, at which point "fine" stops being the word. We run every workload in a **Kata Containers micro-VM**: a real virtual machine with its own kernel, started by the same Kubernetes machinery as an ordinary pod. The isolation boundary is the hypervisor, not a namespace. This matters more than it used to, because a growing share of the code running on platforms like ours was written by a model rather than reviewed by a person. Fly.io reaches the same isolation quality with Firecracker; we are not claiming to be alone in this. What we combine it with — a hard limit and a full agent API — is the part that is ours. ``` your app └─ own kernel ← the boundary └─ kata micro-VM └─ hypervisor └─ node (Rocky Linux 10, LUKS at rest) └─ our rack elsewhere: your app └─ namespace + cgroup └─ shared kernel ← the boundary └─ node, with other customers ``` [Read the security page](/security) ## The parts that make a deploy survivable ### Rollback in one key Ninety days of deploy history. A rollback re-releases a previous image that already built and already passed its health check, so it is a cutover rather than a rebuild — seconds, not minutes. ### A preview per pull request Every pull request gets its own URL with its own environment. They go to sleep on their own when nobody visits them, so having many of them costs very little, and they are cleaned up when the branch is. ### Zero-downtime by default Rolling releases with a startup probe, so traffic only moves once the new version answers. If it never answers, the old one keeps serving and you get told why. ### Services attached, not configured Adding Postgres, Valkey, object storage or a vector index injects the connection variables into your app. You do not copy a connection string anywhere, and rotating a credential does not require a redeploy. ### Cron and background jobs Scheduled tasks and queue workers are first-class workload types with their own logs and their own metrics, priced the same way as everything else. ### Scale to zero, with an alarm clock A workload that nobody is using can sleep and wake on the first request. For production apps you can set a schedule instead, so the first visitor of the morning never pays the cold start. ## Point it at a repository and see. The first deploy tells you more than this page can, and it comes out of the € 10 of credit you start with. - [Create account](https://app.cmdz.com/signup) - [Read the deploy docs](https://docs.cmdz.com/guides/deploy) --- # Terms and conditions > The agreement between you and us for the use of the cmdz hosting platform, including the articles on prepaid credit, its validity and the fact that it is not refundable. The agreement between you and us for the use of the cmdz hosting platform, including the articles on prepaid credit, its validity and the fact that it is not refundable. Last updated: 1 August 2026 · Binadit B.V. · KvK 80923216 Applicable to the use of the cmdz hosting platform. These terms are governed exclusively by Dutch law. ## Article 1 — Definitions - **cmdz:** the service and the platform, operated by Binadit B.V., established in Rotterdam, KvK 80923216, VAT NL861852990B01 ("we", "us"). - **Customer:** the legal entity or natural person that enters into an agreement with us and uses the platform. - **Services:** the hosting platform offered via the portal, the API, the CLI and the MCP server, including the running of applications, managed databases, storage, domain registration and DNS. - **Agreement:** the digital agreement that comes into effect upon the creation of an account and acceptance of these terms. - **Credit:** the prepaid balance, denominated in credits at 1,000 credits = € 1.00 excluding VAT, from which all metered consumption is drawn. - **Limit:** an optional spending cap the Customer may set below their credit balance to bound consumption within a period. ## Article 2 — Applicability These terms apply to any use of the Services. Deviations are valid only if agreed in writing. The applicability of the Customer's purchasing terms is expressly rejected. ## Article 3 — Formation and account The agreement comes into effect when the Customer creates an account, accepts these terms and links a valid payment method. Access to the account is exclusively via passkeys; the Customer is responsible for managing their passkeys and recovery methods. We may refuse a registration or service without stating reasons. ## Article 4 — Prices, limit and payment All prices are exclusive of VAT, unless stated otherwise. Consumption is metered per minute and drawn from the Customer's prepaid credit balance. **The Customer can only consume what they have paid for in advance.** Credit is bought upfront and drawn down by usage in real time; when the balance reaches zero, the platform suspends paid actions instead of continuing to accrue. We never invoice in arrears and never carry a receivable, so no debt can arise. This is a contractual obligation on us, not a setting we may reinterpret. **Credit is not refundable.** Purchased credit is valid for twelve months from the date of purchase and is consumed oldest first; we notify the Customer thirty and seven days before a tranche lapses. Credit granted free of charge by us carries the validity period stated at the time of the grant. No balance — purchased, trial or granted — is convertible into money, on termination or otherwise. Domain registrations, renewals and transfers are **not funded from credit** and are charged separately, visibly in advance, from the payment method, because a registry charges us at the moment of purchase. An invoice is issued at the moment credit is purchased, in accordance with Dutch law and the applicable VAT rules; there is no month-end billing run. ## Article 5 — Availability and service We make every effort to provide the Services with the greatest possible care and manage the infrastructure proactively. Within a region we provide high availability: multiple nodes, replication and failover. Availability across multiple regions — redundancy against the outage of an entire data center — is the responsibility of the Customer, who may use the building blocks we provide for this purpose. We announce planned maintenance at least 48 hours in advance. We are not liable for disruptions beyond our direct control, including outages at third parties or force majeure. ## Article 6 — Liability Our liability is limited to the amount paid by the Customer to us in the three months prior to the event, up to a maximum of € 10,000 per event, or — if higher — to the amount paid out by our liability insurance. We are not liable for indirect damage, consequential damage, lost profit or data loss. The Customer indemnifies us against claims by third parties arising from the content or applications hosted by the Customer. ## Article 7 — Intellectual property All software, documentation and works developed by us remain our property. The Customer retains all rights to their own code, data and content. For the duration of the agreement, the Customer obtains a non-exclusive right to use the platform. ## Article 8 — Confidentiality Both parties keep the other party's confidential information secret. This obligation continues for five years after termination of the agreement. ## Article 9 — Term and termination The agreement is entered into for an indefinite period and may be terminated by the Customer at any time via the portal, subject to the current calendar month. In the event of a material breach, the non-breaching party may terminate the agreement, after written notice of default, with immediate effect. Upon termination, the data remains readable for a short period, after which it is deleted. Any remaining credit balance lapses without payment. Domains follow the expiry process described in the documentation. ## Article 10 — Force majeure We are not liable for failures due to circumstances beyond our reasonable control, including outages at third parties, DDoS attacks, government measures or other force majeure. ## Article 11 — Abuse The [acceptable use policy](/aup) applies to the use of the Services. In the event of a breach thereof, we may act as described in that policy, up to and including immediate suspension. ## Article 12 — Governing law and amendments All agreements are governed exclusively by Dutch law; disputes are submitted to the competent court in Rotterdam. We may amend these terms; amended terms apply to new agreements and, after notice with a period of 30 days, to existing agreements. --- Binadit B.V. · Seinhuiswachter 2, 3034 KH Rotterdam · Netherlands · KvK 80923216 · VAT NL861852990B01 · contact@cmdz.com · +31 10 477 5362 --- # Privacy policy > What personal data we process for our own operations, on what basis, for how long, who the subprocessors are, and what rights you have. What personal data we process for our own operations, on what basis, for how long, who the subprocessors are, and what rights you have. Last updated: 1 August 2026 · Binadit B.V. · KvK 80923216 For the data that you process inside your own applications we act as **processor**, and the [data processing agreement](/dpa) applies to that. This policy covers our own business operations: accounts, billing and this website. ## 1. Data controller Binadit B.V., established in Rotterdam, KvK 80923216, VAT NL861852990B01 is responsible for the processing of personal data described in this policy. Questions: [privacy@cmdz.com](mailto:privacy@cmdz.com). ## 2. What data we process - **Account:** name, company name, email address, and the metadata of your passkeys — never key material. We do not store passwords, because logging in is exclusively with passkeys. - **Billing:** VAT number, address, payment-method references via Mollie (we do not store full card details), and invoices via WeFact. - **Usage:** the technical and consumption data required to provide, meter and secure the Services. - **Website:** minimal, cookieless and EU-hosted usage statistics. No American trackers. - **Communication:** email and support correspondence. ## 3. Purposes and legal bases - **Performance of the agreement** (art. 6(1)(b) GDPR): providing the Services. - **Legitimate interest** (art. 6(1)(f) GDPR): security, fraud prevention and improvement. - **Legal obligation** (art. 6(1)(c) GDPR): tax retention obligation. - **Consent** (art. 6(1)(a) GDPR): any commercial communication. ## 4. Retention periods - Account data: for the duration of the term and up to 6 months after termination, subject to statutory retention obligations. - Billing data: 7 years, under the tax retention obligation. - Runtime logs: 7 days. Build logs: 90 days. - Website statistics: aggregated, up to 14 months. ## 5. Recipients and subprocessors - **Mollie B.V.** (Amsterdam) — payment processing and mandates. - **WeFact B.V.** — billing. - **Hosting Concepts B.V. / Openprovider** — domain registration. - **Cloudflare** — only if you enable Cloudflare DNS or proxy for your own domain. - **Transactional email provider** — outgoing email from the platform. - **Our own infrastructure** — hardware in the data center and region you choose. We do not provide personal data to countries outside the EEA, unless appropriate safeguards under Chapter V GDPR have been put in place, or you yourself choose a region outside the EEA. ## 6. Your rights You have the right to access, rectification, erasure, restriction, data portability and objection (art. 15–21 GDPR). Requests go to [privacy@cmdz.com](mailto:privacy@cmdz.com) and we respond within 30 days. You can file a complaint with the Dutch Data Protection Authority at autoriteitpersoonsgegevens.nl. ## 7. Cookies This marketing site is as cookie-free as we can make it: the only thing stored in your browser is your light or dark theme preference, and that is functional. There are no tracking cookies and no advertising cookies. The portal uses exclusively functional session cookies. ## 8. Security We take appropriate technical and organizational measures: encryption in transit (TLS) and at rest (LUKS2), access based on least privilege, passkeys instead of passwords, isolation of customer workloads in micro-VMs, and regular audits. The [security page](/security) describes this in plain language. ## 9. Amendments and contact We may update this policy; changes are published on this page with a new date. --- Binadit B.V. · Seinhuiswachter 2, 3034 KH Rotterdam · Netherlands · [privacy@cmdz.com](mailto:privacy@cmdz.com) · +31 10 477 5362 --- # Data processing agreement > The GDPR article 28 processing agreement, downloadable and readable here without a sales conversation. It forms an integral part of the agreement. The GDPR article 28 processing agreement, downloadable and readable here without a sales conversation. It forms an integral part of the agreement. Last updated: 1 August 2026 · Binadit B.V. · KvK 80923216 This data processing agreement forms an integral part of the agreement and is drawn up on the basis of art. 28 GDPR. It applies to the processing of personal data that we carry out as **processor** on behalf of you as **controller** when providing the Services. You can read and copy it here without talking to anyone first. ## Article 1 — Subject matter and duration We process personal data solely to provide the Services to you, and only for the duration of the agreement, unless a legal obligation requires longer retention. ## Article 2 — Nature and purpose The processing comprises running, storing and managing the applications and data that you place on the platform. We process solely on your documented instructions, whereby the use of the platform — the configuration you choose — constitutes such instructions. ## Article 3 — Categories of data and data subjects The categories of personal data and data subjects are determined by you, since you decide which data you place on the platform. Typically this concerns data of your employees and the end users of your applications. You do not place special categories of personal data without a valid legal basis. ## Article 4 — Obligations of the processor We undertake to: process only on instructions; ensure confidentiality; take appropriate security measures as described in article 6; assist you with requests from data subjects and with your own GDPR obligations, including data protection impact assessments and notifications; and, upon termination, delete or return all personal data at your choice. ## Article 5 — Subprocessors You grant general authorization for the engagement of subprocessors, provided that we inform you in advance of changes, impose equivalent obligations on those subprocessors, and remain fully liable for their actions. Current subprocessors: Mollie B.V. (payment processing), WeFact B.V. (billing), Hosting Concepts B.V. / Openprovider (domains), Cloudflare (only where you enable Cloudflare DNS), our transactional email provider, and the data center and hardware supplier for the region you selected. The data resides in the region you chose. ## Article 6 — Technical and organizational measures We take measures appropriate to the risk, including: encryption in transit (TLS 1.2 or higher) and at rest (LUKS2); isolation of customer workloads in Kata micro-VMs; access based on least privilege with passkeys; append-only audit logging; backup and recovery procedures with point-in-time recovery for databases; and regular security audits. The full description is available on request. ## Article 7 — Data breaches We report a personal data breach without undue delay, and in any event within 72 hours of becoming aware of it, to you. The report contains at least: the nature of the breach, the categories concerned and the estimated number of data subjects, the likely consequences, and the measures taken or proposed. We document all breaches under art. 33(5) GDPR. ## Article 8 — Transfers outside the EEA We do not transfer personal data outside the EEA, unless an adequacy decision applies or appropriate safeguards such as standard contractual clauses have been put in place. If you yourself choose a region outside the EEA, that choice constitutes an instruction and we inform you about the implications. ## Article 9 — Right to audit You may have compliance with this agreement checked by an independent third party, after written notice of at least 30 days. The costs are borne by you. We provide the reasonably required information. ## Article 10 — Termination Upon termination we delete or return, at your choice, all personal data. Copies are deleted, unless a legal obligation requires retention. We confirm the deletion in writing on request. ## Article 11 — Governing law This data processing agreement is governed exclusively by Dutch law; article 12 of the [terms and conditions](/terms) applies mutatis mutandis. --- Binadit B.V. · Seinhuiswachter 2, 3034 KH Rotterdam · Netherlands · KvK 80923216 · VAT NL861852990B01 --- # Acceptable use policy > What you may and may not run on this platform, how we enforce it, and how to report abuse. In case of conflict between documents, the strictest provision protecting the network, its users or third parties prevails. What you may and may not run on this platform, how we enforce it, and how to report abuse. In case of conflict between documents, the strictest provision protecting the network, its users or third parties prevails. Last updated: 1 August 2026 · Binadit B.V. · KvK 80923216 This policy governs the permitted and prohibited use of cmdz and forms an integral part of the agreement. In the event of conflict between documents, the strictest provision that protects the network, its users or third parties prevails. ## 1. Scope This policy applies to everyone who uses the Services: you, your end users, subaccounts, employees and any third party who obtains access via you. You are responsible for compliance by all of them and remain liable for violations. ## 2. Permitted use The Services may be used solely for lawful purposes, in a manner that does not harm the rights of third parties or the use of the infrastructure by others. Permitted uses include hosting lawful websites and applications, running business workloads, sending transactional email within the anti-abuse limits, and lawfully storing and processing data. ## 3. Prohibited use The categories below are prohibited. The list is not exhaustive; we may designate additional activities as prohibited where they pose legal, operational, reputational or security risks. ### 3.1 Unlawful activity Anything contrary to Dutch law, EU law or the applicable law of the relevant jurisdiction; violation of sanctions and export controls; money laundering, terrorist financing, fraud; and any activity that violates fundamental human rights. ### 3.2 Harmful, abusive or malicious content Hosting, distributing or facilitating child sexual abuse material or non-consensual intimate imagery — this leads to **immediate termination** and reporting to the authorities. Also prohibited: content that incites terrorism, violence or hatred against protected groups; harassment, stalking, doxing and threats; defamatory or fraudulent content; infringement of intellectual property rights, including warez, cracks and piracy; and counterfeiting, forged documents or identity fraud. ### 3.3 Security abuse and network disruption Unauthorized access, scanning or penetration testing of systems you are not permitted to test — tests of your own systems must be reported to us in writing in advance. Also prohibited: distributing or hosting malware, ransomware, spyware or botnet command-and-control; phishing and credential harvesting; denial-of-service, amplification or reflection attacks as source, intermediary or target; IP spoofing, BGP hijacking and DNS poisoning; abuse of the Services as an open relay, open proxy or open resolver; circumventing security or access mechanisms; and excessive resource consumption that degrades the shared infrastructure for others. ### 3.4 Email, messaging and spam Sending unsolicited bulk or commercial email in violation of the Telecommunications Act, the ePrivacy Directive, the GDPR or comparable laws; email with forged headers or without a working unsubscribe option; mailing lists without demonstrable opt-in; and promoting a service via spam regardless of where the spam originates. ### 3.5 Categorically prohibited business categories Regardless of licence or jurisdiction, the following are not permitted: pornography and adult services; online gambling, betting, casinos and games of chance; crypto mixers and tumblers and any service that conceals the origin of digital assets; ICOs, token sales and unregulated financial services; Tor exit nodes and public VPN or proxy services open to unknown third parties; and IPTV, cyberlockers or streaming services that distribute infringing material or link to it. ### 3.6 Other prohibited and high-risk activities **Cryptocurrency mining** and other workloads that deliberately monopolize the shared infrastructure — the platform detects and cuts these off. Also prohibited: services relating to weapons, ammunition, explosives or regulated substances; pyramid and Ponzi schemes; scraping or trading personal data in violation of the GDPR; and generative-AI services that produce non-consensual deepfakes, synthetic identity documents or synthetic child sexual abuse material. ## 4. Compliance with laws and regulations You warrant that your use complies with Dutch law, EU law including the GDPR, DSA, NIS2 and ePrivacy, the law of the jurisdictions in which you operate, and the applicable sanctions and export regimes. You cooperate with a lawful investigation or order of a competent authority and indemnify us against fines or claims arising from your non-compliance. ## 5. Prevention of abuse and harmful content You take reasonable measures against abuse: keeping software up to date, strong authentication, monitoring of logs, rate limiting and anti-bot measures on forms that accept user content, and responding promptly to abuse reports. If you offer a platform with user content, you provide a visible reporting channel and remove unlawful content without undue delay, in accordance with the notice-and-action procedure of the DSA. ## 6. Responsibility for end users You are fully responsible for the conduct of every end user, subuser, employee and third party who obtains access via your account, as if it were your own conduct. You impose at least equivalent obligations on those persons, keep sufficient records to trace the source of abuse, and assist us in investigating complaints. ## 7. Monitoring, enforcement and measures We do not routinely monitor the content of customer traffic or stored data. We may, however, examine traffic patterns, system logs and publicly accessible content to the extent necessary to secure the Services, investigate a suspected violation, comply with a lawful order, or protect third parties. On reasonable suspicion of a violation we may, at our own discretion and without prior notice: warn and request remediation; block or rate-limit traffic, IP addresses, ports or domains; remove unlawful content or quarantine it; suspend the Services in whole or in part; terminate the agreement with immediate effect and without refund in the event of serious, repeated or irreparable violations; and retain data or provide it to authorities where legally required or justified. Violations involving child sexual abuse material, direct threats to life, threats to critical infrastructure, or active attacks on third parties lead to **immediate suspension without prior notice**. We inform you as soon as reasonably possible thereafter, unless the law or an authority prohibits this. ## 8. Reporting abuse Suspected violations or unlawful content on cmdz infrastructure can be reported to [abuse@cmdz.com](mailto:abuse@cmdz.com), with where possible: the IP address, domain or URL concerned, the nature of the complaint, timestamps with time zone, evidence, and your contact details. We acknowledge reports without undue delay and investigate them under our internal abuse procedure. ## 9. Amendments We may update this policy to comply with law, technology or practice. We announce material changes with an updated date and, where they materially affect existing customers, by email with at least 30 days' notice. Continued use after the effective date constitutes acceptance. ## 10. Contact Binadit B.V. · Seinhuiswachter 2, 3034 KH Rotterdam · Netherlands · General: [contact@cmdz.com](mailto:contact@cmdz.com) · Abuse: [abuse@cmdz.com](mailto:abuse@cmdz.com) · +31 10 477 5362 --- # MCP server > 47 tools over Model Context Protocol: create projects, deploy, scale, attach databases, connect domains, read logs, diagnose and explain costs. Five operations are permanently blocked for agents, including raising your limit. https://mcp.cmdz.com/v1 speaks Streamable HTTP, protocol version 2025-06-18, and exposes the entire platform as 47 tools. The same API, the same rights and the same limit as the portal — because the limit is what makes handing over the keys reasonable. https://mcp.cmdz.com/v1 · protocol 2025-06-18 · OAuth 2.1 + PKCE · 47 tools ## Most hosting MCP servers let an agent look. Ours lets it build. Every serious platform in this category now has an MCP server, and we are not going to pretend otherwise — Railway's is genuinely good, Heroku's Postgres tooling is richer than ours on day one, and Cloudflare exposes more API surface than anyone. What almost none of them do is give an agent write access to the whole product *and* a mechanism that makes that safe. That mechanism is the limit. **The limit is not the brake on the agent — the limit is what makes the agent possible.** An agent with a credit card behind it is a liability. An agent with a ceiling is a colleague. The second half is the envelope: every single response carries your limit status, your remaining headroom and the agent's own daily budget. Not only on the cost tools — on all 47. An agent that does something a hundred times in a row must see the brake a hundred times, not once at the beginning. ``` { "ok": true, "data": { … }, "spend_cap": { "used": "412.55", "cap": "500.00", "remaining": "87.45", "used_percent": 82.5, "state": "warning" }, "budget": { "actions_today": 63, "actions_max": 400, "deploys_today": 4, "deploys_max": 10 }, "next_steps": ["Follow with cmdz_wait_for_operation."], "request_id": "req_01J9F2K8QW3ZP6M1" } ``` [How the ceiling works](/hard-limit) ## Three profiles, and five things none of them grant You pick a profile when you authorise an agent, with a passkey, in your own browser. The agent never sees your credentials and never chooses its own scopes. | Profile | Tools | Scopes | What it is for | |---|---|---|---| | read | 22 of 47 | 10 | Look, change nothing. Safe to give to any agent. | | build | 41 of 47 | 16 | Everything needed to go from nothing to live. Cannot permanently delete anything. | | full | 47 of 47 | 19 | Everything, with confirmation on anything destructive. | ### The tool catalogue **Organisation** — cmdz_whoami, cmdz_list_organisations **Projects** — cmdz_list_projects, cmdz_get_project, cmdz_create_project, cmdz_rename_project, cmdz_delete_project **Apps** — cmdz_list_apps, cmdz_get_app, cmdz_scale_app, cmdz_pause_app, cmdz_resume_app, cmdz_restart_app **Deployments** — cmdz_deploy, cmdz_list_deployments, cmdz_get_deployment, cmdz_cancel_deployment, cmdz_rollback, cmdz_promote_preview **Services** — cmdz_list_service_types, cmdz_create_service, cmdz_connect_service, cmdz_quote_service, cmdz_delete_service, cmdz_run_sql **Backups** — cmdz_list_backups, cmdz_create_backup, cmdz_restore_backup **Domains & DNS** — cmdz_list_domains, cmdz_add_domain, cmdz_search_domain, cmdz_buy_domain, cmdz_check_domain_status, cmdz_get_dns_instructions **Environment** — cmdz_list_env, cmdz_set_env, cmdz_delete_env **Observability** — cmdz_get_runtime_logs, cmdz_get_build_logs, cmdz_get_metrics, cmdz_diagnose_app **Cost & limit** — cmdz_get_usage, cmdz_get_spend_cap, cmdz_forecast_spend, cmdz_explain_cost **Operations** — cmdz_get_operation, cmdz_wait_for_operation ### What no profile ever grants - Raise your spending limit - Change your payment details or VAT profile - Dissolve the organisation - Transfer ownership - Manage members ## One command, or six lines of config Authorisation is OAuth 2.1 with PKCE: the client opens your browser, you log in with a passkey, you choose the organisation and the profile, and you confirm. The token is bound to the MCP server, not to the REST API, so a leaked agent token cannot be replayed against the API directly. ### Claude Code ```bash claude mcp add --transport http cmdz https://mcp.cmdz.com/v1 ``` ### Claude Desktop ```json { "mcpServers": { "cmdz": { "url": "https://mcp.cmdz.com/v1" } } } ``` ### Cursor ```json { "mcpServers": { "cmdz": { "url": "https://mcp.cmdz.com/v1" } } } ``` ### Codex ```toml [mcp_servers.cmdz] url = "https://mcp.cmdz.com/v1" ``` ## What stops an agent going wrong Not a system prompt asking it nicely. Five mechanisms, all enforced server-side, all of which work regardless of what the agent believes it has been told. ### The spending limit The same ceiling as everywhere else. An agent cannot raise it, and a reservation that would cross it simply fails. The most an agent can cost you is the number you already agreed to. ### A daily action budget Every agent token has a maximum number of actions and deploys per day, visible in every response. A deploy loop hits that wall long before it hits your wallet. ### Confirmation tokens Destructive operations require a confirmation token that the agent cannot mint itself. It has to come back to you, in your interface, before anything is deleted. ### The emergency stop One button revokes every agent token in the organisation. It takes effect within five seconds, and it is deliberately the most prominent control on the agents screen. ### A separate audit trail Everything an agent did is in the timeline next to what people did, in the brand's agent colour, with the tool name and the request id. Anything an agent changed can be undone from that list. ### Untrusted content is marked Log output, environment variable names, repository content and error text that an agent reads are wrapped and marked as untrusted, so a prompt injection in a log line is data rather than an instruction. ## Written for the thing that has to act on it. An error that says `403 Forbidden` tells an agent nothing it can use, so it retries, and then it retries again. Our errors say what went wrong, whether retrying could ever help, and what the next useful step is. That is not a nicety. An agent that gets a useful refusal stops; an agent that gets an opaque one loops, and a loop is the failure mode that costs money on every other platform. Here it would hit the daily budget and then the limit — but we would rather it simply did not happen. ``` { "ok": false, "error": { "code": "cap_exceeded", "message": "This would reserve 1 240 credits but only 612 remain under the limit.", "retryable": false, "next_steps": [ "Ask the person to raise the limit — you cannot do this yourself.", "Or choose a smaller instance size." ] } } ``` [The full error table](https://docs.cmdz.com/mcp/errors) ## About handing an agent the keys ### Can an agent spend my money? Up to your limit, yes — that is the point of giving it access. Above your limit, no, and there is no path to it: raising the ceiling is one of five operations with no scope, no profile and no tool behind it. ### What if my agent is compromised? Press the emergency stop; every agent token in the organisation is dead within five seconds. Then read the agent timeline, which lists every action with its tool name and request id, and undo what needs undoing. A compromised agent could not have changed your payment details or added a member, because those are permanently blocked. ### Which clients work? Anything that speaks Model Context Protocol over Streamable HTTP — Claude Code, Claude Desktop, Cursor and Codex are the ones we test on every release. Older clients that only speak stdio can use mcp-remote as a bridge. ### Does the MCP server contain any logic of its own? Deliberately none. One tool is one API endpoint, and the only code per tool is the function that shapes the response. There is no services directory and no domain directory in that codebase, and there never will be — what is not there cannot contain a second version of the truth. CI fails if a tool points at an endpoint that is not in the OpenAPI spec. ### Can I use it without MCP? Yes. `cmdz --json` returns exactly the same JSON as the identically named MCP tool, so an agent without MCP support can still drive the platform through the CLI. The REST API at https://api.cmdz.com/v1 is the same surface again. ### Does it cost anything? No. The MCP server and all 47 tools are included on every plan, including the free one. It is not an add-on and it is not a tier. ## Point your agent at it. One command connects Claude Code. Choose the read profile if you want to watch it work before you let it build. - [Create account](https://app.cmdz.com/signup) - [Read the MCP reference](https://docs.cmdz.com/mcp) claude mcp add --transport http cmdz https://mcp.cmdz.com/v1 --- # Pricing > Prepaid credit, metered usage. One thousand credits is one euro, every usage item is listed with an amount — including outbound traffic at € 0.02 per GB — and you can only ever spend what you have already paid. There is no invoice at the end of the month, because there is nothing left to invoice. That sentence comes before the table on purpose — paying first is the product, and the amounts are just where you start. 1 000 credits = € 1.00 excluding VAT · Egress € 0.02/GB · No per-seat price ## There are no plans. There is a balance. No tiers, no seats, no feature gates. Every account has the whole platform and differs only in how much credit is on it. | | Amount | Expires? | What it is for | |---|---|---|---| | Free trial credit | € 10 | After 14 days | Granted on signup once a payment method is verified. Enough to build and run a real app for two weeks. Cannot buy domains or a dedicated IPv4. | | Top-up | From € 5 | After 12 months | Suggested amounts are € 5, € 10, € 25, € 50, or any whole number of euros. € 10 buys 10 000 credits — the rate is fixed and always 1:1. | | Auto-top-up | You choose | After 12 months | Optional. When your balance drops below a threshold you set, we buy more before it runs out, so the charge always precedes the usage. Rate-limited, and you set a daily cap. | Credit you buy is valid for 12 months from the day you buy it, and the oldest top-up is always spent first so a newer one never expires while an older one sits unused. We warn you 30 and 7 days before a tranche lapses. No balance is convertible back into money — paid is paid — and usage always draws down free credit before credit you paid for. ## What does your app cost? Four inputs and one outcome, computed in your browser. Turn on the comparison and it will also show you the profiles where Vercel, Railway or Render come out cheaper than us — nobody believes a calculator in which the vendor always wins. The pricing calculator is interactive on the website. It takes visitors per month, app type, database size, number of preview environments and your limit, and returns an estimated monthly cost with a per-item breakdown, plus what happens if you hit your limit. The rates it uses are the price book on /pricing. ## Every usage item, with an amount No "and more", no "contact us". If an item exists, it is on this page with a price. One thousand credits is one euro, and each item is shown in both. | Item | Unit | Credits | In euros | What that means in practice | |---|---|---|---|---| | Compute | per vCPU minute | 0.05 | € 0.00005 | A 0.5 vCPU app running the whole month: about € 1.10. | | Memory | per GB minute | 0.025 | € 0.000025 | One GB allocated for a month: about € 1.10. | | Storage | per GB month | 150 | € 0.15 | Allocated volume size, not what you have written to it. | | Object storage | per GB month | 100 | € 0.10 | S3-compatible buckets. | | Object operations | per 10,000 | 1 | € 0.001 | Reads and writes against a bucket. | | Outbound traffic | per GB | 20 | € 0.02 | Egress. Vercel charges € 0.15 and Render € 0.15; this is 7.5× cheaper and in line with what a bare-metal host pays. | | Managed database | per instance hour | 2 | € 0.002 | About € 1.46 a month per running instance. Paused instances do not count. | | Backups | per GB month | 10 | € 0.01 | Measured after compression. Restoring costs nothing. | | Vector index | per GB month | 200 | € 0.20 | For retrieval-augmented apps. | | Build minutes | per minute | 1.5 | € 0.0015 | Queue time does not count. Cached builds are shorter. | | Static requests | per million | 300 | € 0.30 | Only for static workloads. | | Email | per accepted message | 2 | € 0.002 | Rejected messages cost nothing. | | IPv6 | per app and service | 0 | free | On by default, on everything. There is nothing to enable and nothing to pay. | | Shared IPv4 ingress | per app and service | 0 | included | How your site is reachable over IPv4. One address serves thousands of apps, routed by hostname — this is how every modern platform works. | | Dedicated IPv4 | per address per month | 7,500 | € 7.50 | On request, limited availability. Almost nobody needs one — see below. | Domain names are the one thing that falls outside your limit: a registration is a purchase from a registry, paid on a card at the moment you buy it, at cost plus a fixed 25% margin with the renewal price shown before you confirm. ## You do not need an IP address of your own. **Almost nobody needs a dedicated IPv4 address**, and if you are unsure, you do not. Your site answers on both IPv4 and IPv6 the moment it deploys, over our shared ingress — you point your domain at it with a CNAME or an A record and we work out which app a visitor wants from the hostname they asked for. A dedicated address is only for the few cases that need a stable, exclusive IP: a raw TCP or UDP service, or a third party that will only talk to an address on their allowlist. Because IPv4 is genuinely scarce, it is a gated add-on — on request, in limited quantity, and only where we have headroom — at € 7.50 a month plus a possible one-time provisioning fee. It is deliberately not a checkbox at signup. | Networking | What you pay | |---|---| | IPv6 | Free, on by default | | Shared IPv4 ingress | Included | | Automatic HTTPS certificates | Included | | Unlimited custom domains on an app | Included | | Dedicated IPv4 | € 7.50/mo · on request, limited availability | [How networking works](/features#networking) ## What costs nothing extra With checkmarks and without reservation, because a list like this is only worth anything if it has no asterisk. ### HTTPS certificates Requested and renewed automatically, wildcards included. ### Preview environments As many as you have pull requests. They sleep on their own. ### Log retention 7 days of runtime logs, 90 days of build logs. ### Metrics Thirteen months of history. ### Daily backups Including restoring them. ### Extra domains Unlimited per app. Render charges $0.25 per domain per month. ### Extra team members No price per seat. Vercel charges $20 per extra paid seat. ### IPv6 On by default, on every app and every service. Free, and nothing to configure. ### Shared IPv4 ingress Your site answers on IPv4 and IPv6 from the moment it deploys. You do not need an IP address of your own. ### DDoS protection and HTTP/3 Standard on every workload. ### The MCP server and all 47 tools Not an add-on, not a plan tier. ### Support From someone who can reach the servers. ## Compute, memory, traffic, storage, databases and domains. Those are the six things you pay for, and they are all in the table above with an amount next to them. Everything else on this platform is either included or does not exist. We show the price **before** anything starts. Adding a database quotes you the monthly cost first; scaling an app shows what the new size does to your monthly run rate; buying a domain shows the renewal price, not just the first-year price. A confirmation card with the price on it is a brand rule here, not a courtesy. If a charge ever surprises you, that is a bug in how we communicated, and we would like to hear about it. ``` $ cmdz quote postgres --size small instance 1 × small 2 credits/hour storage 5 GB 150 credits/GB/month backups 5 GB 10 credits/GB/month ──────────────────────────────────────────── estimated 2 260 credits/month = € 2.26 after this your balance covers 3.4 more months. create it? [y/N] ``` [What happens when the credit runs out](/hard-limit) ## The ones that decide it ### Why credits instead of euros? Because a vCPU minute costs a fraction of a cent and an invoice full of numbers like € 0.00005 is unreadable. One thousand credits is one euro, exactly and always, and every item is shown in both units so nobody has to do arithmetic to know what something costs. ### What do you charge for outbound traffic? € 0.02 per GB, which is 7.5× cheaper than the € 0.15 that Vercel and Render charge and in line with what a bare-metal host pays. We do not pretend it is free — it is a real cost and it is on this page with a number next to it. What it cannot do here is surprise you, because it draws down credit you already bought rather than appearing on an invoice afterwards. ### What if I outgrow this? You buy more credit and keep going; there is no tier to graduate to and no gate to hit. What we do not do is a procurement process, a SOC 2 attestation or a multi-region contract — if you need those, we would rather tell you now that we are not the right platform than sell you a roadmap. ### Is there a free tier that stays free? No, and we would rather be blunt about it than dress up a crippled one. You get € 10 of credit for 14 days and after that you buy credit from € 5. A permanent free tier is paid for by the paying customers, which is how free tiers quietly get worse; we would rather charge honestly and keep the platform predictable for the people funding it. ### Can I get money back if I do not use my credit? No. Paid is paid: no balance is convertible back into money, on closure or otherwise. What you buy stays spendable for 12 months and we warn you before a tranche lapses, so the way to avoid losing credit is to buy in the amounts you actually use — the minimum is € 5 for exactly that reason. ### How do I pay? iDEAL, SEPA direct debit or credit card, charged at the moment you buy credit. You get a proper VAT invoice for that purchase there and then — not a month later, because there is no month-end billing run. Domain purchases are charged separately on a card because a registry charges us immediately. ### Do prices change? When they do, we publish the change with a date and a reason in a public log with an RSS feed, and price increases never apply retroactively to a period you have already started. ## Try the numbers on your own app. The calculator on this page runs entirely in your browser. Nothing you type in it is sent anywhere. - [Start with € 10 of free credit](https://app.cmdz.com/signup) - [How running out works](/hard-limit) --- # Regions > Choose the region your app and data live in. Within a region we handle high availability; across regions you arrange your own redundancy with the building blocks we give you. A region is a physical location where we run a cluster: a rack or hall with its own power, network and cooling path. Your app, its databases, its volumes, its backups and its logs live in the region you choose and do not leave it. 3 regions available · 3 on the roadmap · Data residency is a guarantee, not a setting ## Where we run today, and where we are going The Netherlands is the flagship and the default. Frankfurt is open. London, New York and Singapore are on the roadmap — we list them as planned rather than as coverage, because a region that does not exist yet is not a feature. | Region | Location | Status | Latency from Amsterdam | Data residency | |---|---|---|---|---| | nl-rtm-1 | Rotterdam, Netherlands | available | 1 ms | Netherlands / EEA | | nl-ams-1 | Amsterdam, Netherlands | available | 2 ms | Netherlands / EEA | | de-fra-1 | Frankfurt, Germany | available | 8 ms | Germany / EEA | | uk-lon-1 | London, United Kingdom | planned | 7 ms | United Kingdom | | us-nyc-1 | New York, United States | planned | 78 ms | United States | | sg-sin-1 | Singapore, Singapore | planned | 165 ms | Singapore | Latency figures are indicative, measured from Amsterdam. Price can differ slightly per region because power, hardware and connectivity differ per location; you see the price for your region before you create anything, and the ceiling works the same everywhere. ## What a region does and does not promise ### Within a region: we handle it Multiple nodes, at least two replicas, database failover and replicated storage. A node dying is our problem and you should not notice it. ### Across regions: you choose Run the same app in two regions and split the traffic. We give you the building blocks — per-region environments, health-driven DNS, cross-region read replicas — and you choose the level of redundancy and the recovery objective you actually need. ### What we do not promise Automatic, seamless failover between regions. Not in this version. Saying so now is worth more than saying it after an outage, and anyone who tells you otherwise about their own platform is worth a second question. ### Data residency Choose an EU region and your data stays in the EEA, including its backups and its logs. The data processing agreement names the country and the data center per region, and you can download it without a sales call. ### Region is per environment Not per account. Production in Rotterdam and staging in Frankfurt is an ordinary configuration, and the region is visible on the environment, the app, the database and the invoice. ### Moving regions Redeploy in the target region and migrate the data through a backup restore. It is a deliberate operation rather than a live migration, and the path exists and is documented. ## What running in two regions actually involves Create a second environment of the same project in another region and deploy the same commit to it. Put health-driven DNS in front of both: multiple A and AAAA records with health checks, so a region that stops answering drops out of the rotation. For state, run your database in one region as the primary and a **read replica** in the other. Writes stay in the primary region; synchronous multi-region writes are out of scope, and we would rather be clear about that than sell you a consistency model we have not built. The result is a setup that survives a data center outage with a short interruption for writes, at roughly double the compute cost of a single-region setup — which you can see in the calculator before you commit to it. ``` $ cmdz env create production-fra --region de-fra-1 ✓ environment created · de-fra-1 $ cmdz deploy --env production-fra ✓ live · 2 replicas · de-fra-1 $ cmdz db replica add --from nl-rtm-1 --to de-fra-1 ✓ read replica streaming · lag 240 ms $ cmdz domains health-dns linktree.dev \ --targets nl-rtm-1,de-fra-1 ✓ A/AAAA × 2 · health check every 10 s a failing region leaves the rotation in ~30 s ``` [Calculate what that costs](/pricing#calculator) ## About regions and residency ### Which region do I get if I do not choose? Rotterdam, the default. You can change it per environment when you create one; you cannot silently be moved to another region afterwards. ### Can my data end up outside the EEA? Only if you put an environment in a region outside it yourself. Our EU regions keep everything — app, database, volumes, backups, logs — inside the EEA, and the subprocessor list in the data processing agreement names the supplier per region. ### Why so few regions? Because we own the hardware rather than renting capacity, and a region is a rack we paid for. That is the same reason the limit can exist. Regions open as hardware lands, and we list the ones that are not open yet as planned rather than as coverage. ### Do I get my own IP address in my region? You do not need one, and by default you do not have one. Every region gives your app free IPv6 and a shared IPv4 ingress with automatic certificates, so a custom domain is a CNAME or an A record and it works the same way in every region. A dedicated IPv4 is the exception — for a raw TCP or UDP service, or a third party that only talks to an address on their allowlist. It is € 7.50 a month, on request, and availability is per region: we only issue one where that region has address headroom. ### Does the price differ per region? It can, slightly — power, hardware and connectivity differ per location, so the price book can carry a region factor. You see the price for your region before you create anything, and your ceiling behaves identically everywhere. ### What if a region is full? It is marked as limited or full and no new environments land in it until we add capacity. Existing workloads in it are unaffected, and you can create the new environment in another region in the meantime. ### I have users in Asia today. Should I use you? Not for latency-critical traffic, not yet. Singapore is on the roadmap and it is not open. We would rather tell you now than have you find out from a latency graph. ## Pick a region and deploy into it. It is a dropdown when you create an environment, and it is on every screen afterwards so you never have to wonder where something lives. - [Create account](https://app.cmdz.com/signup) - [Read the security page](/security) --- # Security > Real VM isolation with Kata micro-VMs, passkeys only with no password to steal, encryption at rest, an audit trail per action, and a data processing agreement you can download without a sales call. More of the code running on platforms like this one was written by a model than by a person who read it line by line. That changes what an isolation boundary has to be worth. Kata micro-VMs · Passkeys only · Encrypted at rest · GDPR, EU regions ## Four layers, and where each one stops ### Your app runs in its own kernel Every workload is a Kata Containers micro-VM: a real virtual machine started by the same Kubernetes machinery as an ordinary pod, with its own kernel and its own memory. A container escape on a shared-kernel platform reaches the host. Here it reaches a kernel that belongs to one customer and nothing else. Fly.io achieves the same thing with Firecracker — this is not an exclusive claim, and we are not going to make it sound like one. ### Network segmentation per project Workloads can reach their own services and the internet, and nothing else. There is no flat internal network, and there is no path from one customer's app to another's database, however the connection string is constructed. ### Encrypted at rest, unlocked on boot Full-disk encryption on every node, with keys released by a network-bound unlock service rather than stored on the machine. A disk that leaves the rack is a brick. ### Secrets are never in the repository Environment variables and secrets live encrypted in the platform. `cmdz env pull` writes names, never values — including for an agent, which can see that a `DATABASE_URL` exists but never what it is. ## There is no password to steal. Logging in is a passkey and nothing else. No password, no username, no email with a code, no authenticator app. Phishing a passkey is not a matter of a convincing email — the credential is bound to the origin and simply will not present itself to a lookalike domain. We do not support passwords as a fallback, and we will not add one on request. A fallback that is weaker than the primary method is the security level of the account. Two boundaries sit behind that. The platform lives on `cmdz.com` and customer apps live on `cmdz.app` — a separate domain, deliberately, so a customer app can never see a platform session cookie or a platform passkey. And the admin interface additionally requires an IP allowlist and a fresh passkey confirmation for anything that touches a customer. - **Passkeys only**, no password fallback, ever - **Step-up confirmation** for destructive and financial actions - **Separate domain for customer apps**, so cookie and passkey scopes cannot overlap - **Sessions are revocable** per device, and revocation is immediate - **Recovery** through a second passkey or a signed recovery code you store yourself ``` 09:14 ronald deployed web #412 09:31 claude-code cmdz_scale_app 2→3 agent 09:31 claude-code cmdz_get_metrics agent 10:02 ronald raised limit €20 → €35 10:44 claude-code cmdz_create_service agent 10:44 claude-code cap_exceeded (refused) agent 11:20 ronald rolled back web #412→#411 every line: actor · tool · request id · undo ``` ## The security case for handing over the keys An agent with platform access is a new class of risk and pretending otherwise would be dishonest. Here is what actually contains it. ### A financial ceiling it cannot move The blast radius of a compromised agent is bounded by a number you set, because raising that number is not something any token can do. ### A daily action budget Separate from the limit and much smaller. An agent in a loop stops at the budget long before the ceiling, and you get told. ### A five-second kill switch One button revokes every agent token in the organisation. It is the most prominent control on the agents screen, on purpose. ### Untrusted content is marked as such Log lines, error text, repository content and variable names that an agent reads are wrapped and labelled untrusted, so a prompt injection planted in a log is data rather than an instruction. ### Confirmation the agent cannot forge Destructive operations need a token that only your interface can produce. The agent has to come back to you. ### Five permanent blocks Raising the limit, changing payment details, dissolving the organisation, transferring ownership, managing members. No scope, no profile, no tool. [The full agent safety model](/mcp) ## The paperwork, downloadable without a conversation. The data processing agreement, the privacy policy, the terms and the acceptable use policy are on this site as ordinary pages. You can read them, copy them and send them to your own counsel without giving us an email address first. Data residency follows the region you pick: choose an EU region and your data, its backups and its logs stay in the EEA. The subprocessor list names the supplier and the data center per region, and it changes with notice rather than quietly. We are not SOC 2 attested and we do not have a compliance department. If your procurement process requires one, we are honestly not the right platform for you yet, and we would rather say that on this page than three meetings in. - **Data processing agreement** under GDPR article 28, downloadable here - **Subprocessors listed per region**, with changes announced in advance - **Breach notification** within the statutory window, to you and where required to the regulator - **Export everything** at any time, in standard formats - **Deletion on termination**, with the retention windows written down [Read the data processing agreement](/dpa) ## If you find something, tell us. Email **security@cmdz.com**. We acknowledge within one working day and we will tell you what we found and when we fixed it. We do not have a bug bounty programme and we are not going to pretend we do; what we do have is someone who reads that mailbox and can reach the servers. We ask for the ordinary things: give us a reasonable window before publishing, do not access data that is not yours, and do not run anything that degrades the service for other customers. In return we will not threaten you, and we will credit you if you want to be credited. ``` Contact: mailto:security@cmdz.com Policy: https://www.cmdz.com/security Preferred-Languages: en, nl # Acknowledged within one working day. # No bounty programme. A real person, though. ``` [Read the acceptable use policy](/aup) ## Read the agreements before you sign up, not after. All four legal documents are ordinary pages on this site. No form, no sales call, no gated PDF. - [Data processing agreement](/dpa) - [Privacy policy](/privacy) --- # Blog > Guides, product notes and engineering writing from the people who own the hardware: shipping AI-built apps, the hard limit, agents over MCP, regions and sovereignty. What we are building and why, written the way we would explain it to you in person. One post a week, and every post is also available as raw Markdown for the agents reading along. 20 posts · Product · Guides · AI & agents · Sovereignty · Engineering · Comparisons - **[Ship an AI-built app in 90 seconds: from git URL to live](/blog/ship-an-ai-built-app-in-90-seconds)** (Guides, 22 Jul 2026) — 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. - **[The hard spending limit: why we cap instead of billing you more](/blog/the-hard-spending-limit)** (Product, 15 Jul 2026) — Every platform has a budget setting. Almost none of them stop the bill. Here is the mechanical difference, the balance sheet that makes it possible, and the two things that fall outside it. - **[Let an agent run your infrastructure: MCP, scopes and safety](/blog/let-an-agent-run-your-infrastructure)** (AI & agents, 8 Jul 2026) — Giving a model write access to your production platform sounds reckless. It is reckless — unless the blast radius is a number you set. Here is the full safety model, mechanism by mechanism. - **[Connect Claude Code, Codex or Cursor to cmdz over MCP](/blog/connect-claude-code-codex-cursor-over-mcp)** (AI & agents, 1 Jul 2026) — The configuration for each client, what the authorisation flow actually does, how to pick a profile, and how to tell whether it is working. - **[Passwordless from day one: how passkeys work on cmdz](/blog/passwordless-from-day-one)** (Product, 24 Jun 2026) — No password, no username, no emailed code, no authenticator app. What that means in practice, what happens when you lose a device, and why we will not add a fallback. - **[Deploy a Next.js + Postgres app without writing a Dockerfile](/blog/nextjs-postgres-without-a-dockerfile)** (Guides, 17 Jun 2026) — The most common stack on this platform, end to end: detection, the database, migrations on release, environment variables, preview environments and what the whole thing costs. - **[Deploy Laravel on cmdz: Octane, migrations and queues](/blog/deploy-laravel-octane-migrations-queues)** (Guides, 10 Jun 2026) — A real Laravel deployment: the release command, queue workers as their own workload, the scheduler, Octane, storage on object storage, and where the horizontal-scaling surprises are. - **[Deploy FastAPI with a vector database for RAG](/blog/fastapi-with-a-vector-database-for-rag)** (Guides, 3 Jun 2026) — A retrieval-augmented app end to end: FastAPI on Uvicorn, pgvector, where the embedding cost actually lands, and why the spending limit matters more for this shape of app than any other. - **[Choosing a region: data residency and your own redundancy](/blog/choosing-a-region)** (Sovereignty & regions, 27 May 2026) — What a region actually guarantees, what it does not, and how to run one app in two of them — including the honest limits of what we promise across regions. - **[Buy a domain and manage DNS in one place](/blog/buy-a-domain-and-manage-dns-in-one-place)** (Guides, 20 May 2026) — Search, buy, attach and certify in one flow — plus why domains are the one thing charged outside your spending limit, and why we always show the renewal price. - **[Preview environments per pull request, explained](/blog/preview-environments-per-pull-request)** (Guides, 13 May 2026) — What gets created, what is shared with production and what is not, how sleeping keeps twenty of them nearly free, and the two mistakes that make previews expensive. - **[What counts toward your limit — and what does not](/blog/what-counts-toward-your-limit)** (Product, 6 May 2026) — The complete list, both columns, including the two things outside the ceiling and the reason for each. No "and more", no asterisks. - **[cmdz vs a hyperscaler: cost predictability for AI builders](/blog/cmdz-vs-a-hyperscaler)** (Comparisons, 29 Apr 2026) — Three concrete workloads priced against the published rates of Vercel, Railway, Render, Fly and Cloudflare — including the two profiles where they win. - **[EU data, EU law: what sovereignty actually means for your stack](/blog/eu-data-eu-law)** (Sovereignty & regions, 22 Apr 2026) — Beyond the region dropdown: where the control plane lives, where the logs and backups go, who the subprocessors are, and which questions to ask any provider claiming an EU region. - **[Scaling to zero and back: how cold starts work](/blog/scaling-to-zero-and-back)** (Engineering, 15 Apr 2026) — What actually happens between a request arriving at a sleeping app and it being served, where the milliseconds go, and when scale-to-zero is the wrong choice. - **[Rollbacks in seconds: the 90-day deploy history](/blog/rollbacks-in-seconds)** (Product, 8 Apr 2026) — Why a rollback here is a cutover rather than a rebuild, what it does and deliberately does not undo, and how to make your migrations rollback-safe. - **[Metering explained: how usage becomes credits](/blog/metering-explained)** (Engineering, 1 Apr 2026) — The full chain from a 15-second sample to a line on your invoice: what we measure, how precise it is, which way the imprecision points, and why rounding happens exactly once. - **[Secrets and environment variables, done right](/blog/secrets-and-environment-variables)** (Guides, 25 Mar 2026) — Where secrets live, why `env pull` writes names and never values, what an agent can and cannot see, and how to rotate a credential without a redeploy. - **[How we isolate customer workloads with Kata micro-VMs](/blog/how-we-isolate-workloads-with-kata)** (Engineering, 18 Mar 2026) — The difference between a namespace and a hypervisor as a security boundary, what it costs in memory and boot time, and why it matters more now that a model wrote the code. - **[Building an app entirely by talking to an agent: an end-to-end walkthrough](/blog/building-an-app-entirely-by-talking-to-an-agent)** (AI & agents, 11 Mar 2026) — A complete session from empty directory to a live app on a custom domain, without touching a dashboard — including the two moments the agent had to come back and ask. --- # 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) --- # The hard spending limit: why we cap instead of billing you more > Every platform has a budget setting. Almost none of them stop the bill. Here is the mechanical difference, the balance sheet that makes it possible, and the two things that fall outside it. Every platform has a budget setting. Almost none of them stop the bill. Here is the mechanical difference, the balance sheet that makes it possible, and the two things that fall outside it. 15 Jul 2026 · 4 min read · cmdz Nearly every hosting platform lets you set a budget. Almost none of them let that budget bind them. Read the documentation carefully and you find the sentence. Vercel's is the clearest: *"Setting a spend amount does not automatically stop usage."* The check runs every few minutes; pausing happens after the fact, only on Pro, only if you turned it on, and seats and marketplace add-ons fall outside it entirely. That is not dishonest. It is what a budget alarm is. It is just not what most people think they bought. ## The mechanical difference The difference is not the size of the number. It is **when the check happens.** A budget alarm samples your accrued spend on an interval and reacts. By the time it fires, the spend already happened, so the only question left is who pays for it. The answer is you. A hard limit checks *before* the spend. Every minute a job prices what ran in the previous minute and books it against your ceiling. Before anything expensive begins — a build, a new database, an extra replica, a bigger instance — the platform reserves the credits it expects to consume and refuses the operation if the reservation does not fit. ``` remaining = cap − used − reserved if remaining < 0: the operation does not start ``` Three lines, and they are the product. A reservation that fails simply does not let the expensive thing happen, so there is no invoice to argue about afterwards. ## Why we can afford this and a reseller cannot This is the part that decides whether you believe the rest. A platform that buys capacity from a hyperscaler pays per gigabyte transferred, per gigabyte stored and per CPU second. Their cost curve tracks your usage almost exactly. Passing that through **is** their margin. For them, a ceiling is not stubbornness — it is a loss they eat, on purpose, forever. Our costs are mostly fixed. We own the machines and depreciate them over years. The rack space is a monthly amount. The transit is committed rather than metered per gigabyte. A customer who hits their ceiling costs us **capacity we already paid for**, not a purchase invoice. That is the whole trick, and it is not clever. It is a different balance sheet. It is also why we can write the sentence without an asterisk, and why a platform built on rented capacity cannot copy it in a sprint without damaging its own model. ## What happens when you hit it Your apps pause. Visitors get an error page from the edge — not a dropped connection. Then the list of things that do **not** happen, which is the part people actually worry about: - Your data is not deleted. Not the database, not the volumes, not the object storage. - Your backups keep the snapshots they already have. - Your domains keep resolving and your certificates keep renewing. - Your environment variables and secrets are untouched. - No invoice follows. Not that month, not later, not as a back-charge. At the new billing period everything starts again by itself. If you would rather not wait, raise the limit and the workloads come back within seconds. You can raise it whenever you like. An AI assistant cannot, no matter how the request is phrased — that is one of five operations with no scope, no profile and no tool behind it. ## The two things outside the ceiling We would rather list these plainly than have you find them. **Domain registrations and renewals.** A registry charges us at the moment of purchase and the name is yours for a year. If domains were inside the limit, a paused workload could cost you a domain name, which is a worse outcome than a separate charge. They are billed on a card, at cost plus a fixed 25% margin, with the renewal price shown before you confirm. **VAT.** The ceiling is on the amount excluding VAT. VAT is added according to your tax status, because we do not get to decide that. Everything metered — compute, memory, storage, databases, backups, builds, requests — is under the ceiling. ## "Can you make an exception, just once?" No, and the reason is worth stating. The moment we grant one exception, the promise becomes a policy with discretion in it. A policy with discretion is exactly the thing this product exists to replace, because you cannot plan around discretion and you certainly cannot plan around someone else's. Raise your limit instead. It takes seconds and it is entirely yours to do. ## Where the competition actually stands Railway has a real hard limit — minimum $10, and hitting it takes workloads offline, which they themselves describe as a possibly destructive action. Netlify's prepaid credit model effectively caps you as long as auto-recharge is off. Neither of those is nothing, and we would rather say so here than have a stranger say it for us in a thread. The rest — Render, Fly, DigitalOcean, Cloudflare — bill the overage. Cloudflare caps CPU time per invocation, which bounds a runaway function but not an invoice. The [comparison table](/hard-limit#competition) has all of it, including the places where they beat us. ## 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) --- # Let an agent run your infrastructure: MCP, scopes and safety > Giving a model write access to your production platform sounds reckless. It is reckless — unless the blast radius is a number you set. Here is the full safety model, mechanism by mechanism. Giving a model write access to your production platform sounds reckless. It is reckless — unless the blast radius is a number you set. Here is the full safety model, mechanism by mechanism. 8 Jul 2026 · 5 min read · cmdz "An agent may do everything you may" is a frightening sentence without a ceiling and a reasonable one with it. This post is about what makes the second version true. ## Start with the honest version of the risk An agent with platform access can create things that cost money, delete things you needed, and read things you would rather it did not. It can also be talked into doing all three by text it encounters while working — a log line, an error message, a README in a dependency. Nothing about a system prompt fixes that. "Please do not delete the production database" is a request, and requests are not a security boundary. What follows are the six mechanisms that are. ## 1. The spending limit The blast radius of a compromised or confused agent is bounded by a number you already agreed to. Anything that would cross the ceiling fails **before** it starts, with an error that says so. Crucially, raising that number is not something any token can do. It is one of five permanently blocked operations. An agent that decides the correct solution to `cap_exceeded` is a bigger cap discovers there is no tool for it. This is the load-bearing mechanism. The other five are refinements on it. ## 2. Scopes, in three presets When you authorise an agent, you pick a profile — in your own browser, with a passkey. The agent never chooses its own scopes and never sees your credentials. | Profile | Tools | What it is for | |---|---|---| | `read` | 22 of 47 | Look, change nothing. Safe for any agent. | | `build` | 41 of 47 | Everything needed to go from nothing to live. Cannot permanently delete anything. | | `full` | 47 of 47 | Everything, with confirmation on destructive operations. | `build` is the default, and the reason is that all three `*:delete` scopes are absent from it. An agent on `build` can create a project, deploy it, scale it, attach a database, connect a domain and diagnose it — and cannot throw any of it away. For most people that is precisely the shape of trust they want. Note that `read` includes `env:read`. That gives the **names** of environment variables, never the values. An agent that has to understand your app needs to know a `DATABASE_URL` exists; it does not need to know what it is. ## 3. A daily action budget Separate from the limit, and much smaller. Every agent token has a maximum number of actions and deploys per day. This exists because the failure mode that actually happens is not a malicious agent — it is a loop. An agent that misreads an error and retries forever hits the action budget in minutes, long before it approaches your ceiling, and you get told about it. The budget is in every response, alongside the spend cap: ```json "budget": { "actions_today": 63, "actions_max": 400, "deploys_today": 4, "deploys_max": 10 } ``` ## 4. Confirmation tokens Destructive operations require a confirmation token that the agent cannot mint. It has to come from your interface, which means it has to come back through you. An agent can propose `cmdz_delete_project`. It cannot complete it alone, and there is no phrasing that changes that, because the check is on the server and the server does not read the conversation. ## 5. The emergency stop One button revokes every agent token in the organisation. It propagates in under five seconds — measured, not estimated. It is deliberately the most prominent control on the agents screen. A safety mechanism you have to look for is not one you will find at the moment you need it. Afterwards, the agent timeline lists every action with its tool name, its arguments and its request id, in the brand's agent colour next to what people did. Anything an agent changed can be undone from that list. ## 6. Untrusted content is marked as untrusted An agent reading your build log is reading text written by your dependencies. An agent reading an error message is reading text that may have come from user input three layers down. All of it — log output, error text, repository content, environment variable names — is wrapped and labelled untrusted before it reaches the model. A prompt injection planted in a log line arrives as data with a fence around it rather than as an instruction in the middle of a tool result. This is not a solved problem in the industry and we are not going to claim it is. Marking the boundary is the part we can do reliably; the rest is the client's job, and it is one of the reasons we keep the destructive operations behind a token the agent cannot produce. ## The envelope Every single response — all 47 tools, not just the cost ones — carries your limit status: ```json "spend_cap": { "used": "412.55", "cap": "500.00", "remaining": "87.45", "used_percent": 82.5, "state": "warning" } ``` The reason is small and important: an agent that does something a hundred times in a row must see the brake a hundred times, not once at the beginning. Context windows forget. The last response is what a model reads best. ## The errors are written for the agent `403 Forbidden` tells an agent nothing actionable, so it retries. Our refusals say what happened, whether retrying could ever help, and what to do instead: ```json "error": { "code": "cap_exceeded", "message": "This would reserve 1 240 credits but only 612 remain under the limit.", "retryable": false, "next_steps": [ "Ask the person to raise the limit — you cannot do this yourself.", "Or choose a smaller instance size." ] } ``` A useful refusal ends a loop. An opaque one starts a longer one. ## Connecting it ```bash claude mcp add --transport http cmdz https://mcp.cmdz.com/v1 ``` OAuth 2.1 with PKCE, a passkey in your browser, pick the organisation, pick the profile, confirm. Start on `read` if you want to watch it work before you let it build. Everything above is on [the MCP page](/mcp). ## 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) --- # Connect Claude Code, Codex or Cursor to cmdz over MCP > The configuration for each client, what the authorisation flow actually does, how to pick a profile, and how to tell whether it is working. The configuration for each client, what the authorisation flow actually does, how to pick a profile, and how to tell whether it is working. 1 Jul 2026 · 3 min read · cmdz Four clients, four snippets, one endpoint. Then the part nobody documents: how to tell whether it actually worked. ## The endpoint ``` https://mcp.cmdz.com/v1 ``` Streamable HTTP, protocol version `2025-06-18`. `POST` for client-to-server messages, `GET` for the SSE stream the server uses to push progress on long operations. There is no stdio server to install and nothing to keep running on your machine. ## Claude Code ```bash claude mcp add --transport http cmdz https://mcp.cmdz.com/v1 ``` That is the whole configuration. The first tool call triggers the authorisation flow. ## Claude Desktop ```json { "mcpServers": { "cmdz": { "url": "https://mcp.cmdz.com/v1" } } } ``` ## Cursor Same shape, in `.cursor/mcp.json` for a single project or in the global settings for all of them: ```json { "mcpServers": { "cmdz": { "url": "https://mcp.cmdz.com/v1" } } } ``` ## Codex ```toml [mcp_servers.cmdz] url = "https://mcp.cmdz.com/v1" ``` ## Clients that only speak stdio Some older clients cannot do remote MCP servers. Bridge with `mcp-remote`: ```json { "mcpServers": { "cmdz": { "command": "npx", "args": ["-y", "mcp-remote@latest", "https://mcp.cmdz.com/v1"] } } } ``` Prefer the direct HTTP route where your client supports it — fewer moving parts, and the bridge is one more process that can be out of date. ## What the authorisation flow actually does The first tool call gets a `401` with a pointer to our protected-resource metadata. Your client discovers the authorisation server, generates a PKCE challenge and opens your browser. In that browser you: 1. Log in with a passkey. No password exists to phish. 2. Choose the organisation, if you belong to more than one. 3. Choose a profile — `read`, `build` or `full`, or customise the scopes. 4. Confirm with a step-up passkey check. The token that comes back is bound to `https://mcp.cmdz.com` as its audience. It does **not** work against the REST API directly, which means a leaked agent token cannot simply be replayed somewhere else. Your role limits what you can grant. A viewer who tries to authorise `full` is told, in the consent screen, that their role does not carry that profile. ## Picking a profile Start on `read` for a day if you have not done this before. Watch what it looks up and what it concludes; it costs nothing and it is genuinely informative about how a model reasons about infrastructure. Move to `build` when you want it to actually do things. This is the default, and its defining property is that all three delete scopes are missing — an agent on `build` can create anything and destroy nothing. Take `full` only when you have a reason, and know that destructive tools still need a confirmation token from your own interface. ## Telling whether it worked Ask it something read-only: ``` > what is my cmdz spend cap right now? ``` A working connection answers with real numbers, because `cmdz_get_spend_cap` returned them. A broken one produces a plausible-sounding paragraph with no numbers in it, which is the failure mode worth learning to recognise. Then check the envelope. Every response carries this, on all 47 tools: ```json "spend_cap": { "used": "12.40", "cap": "20.00", "state": "healthy" }, "budget": { "actions_today": 3, "actions_max": 400 } ``` If your client shows raw tool results, you will see it. If it does not, ask the agent what your remaining headroom is — it read it, whether or not it mentioned it. ## When something goes wrong `cmdz --debug` is the fastest path. Every CLI command takes `--json` and returns **exactly the same JSON** as the identically named MCP tool, so you can reproduce what the agent saw without the agent in the way: ```bash cmdz apps list --json ``` If that works and the MCP call does not, the problem is in the client or the token, not in the platform. That equivalence is deliberate — it is also why an agent with no MCP support at all loses nothing by driving the CLI instead. ## A first task worth giving it ``` > deploy this repo to cmdz, give it a postgres database, and tell me what it will cost per month ``` It will create the project, quote the database before creating it, deploy, wait for the health check, and report the run rate against your ceiling. If any of that would cross the limit, it stops and tells you it cannot raise it. That last sentence is the entire reason this is safe to try. ## 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) --- # Passwordless from day one: how passkeys work on cmdz > No password, no username, no emailed code, no authenticator app. What that means in practice, what happens when you lose a device, and why we will not add a fallback. No password, no username, no emailed code, no authenticator app. What that means in practice, what happens when you lose a device, and why we will not add a fallback. 24 Jun 2026 · 4 min read · cmdz There is no password field anywhere on this platform. Not hidden behind "advanced", not as a fallback, not on request. That decision has consequences, some of which are inconvenient, and this post is about all of them. ## What logging in looks like You click "log in". Your browser asks your device to prove it holds the key. You touch a fingerprint sensor, look at a camera, or type your device PIN. You are in. No username. No email address. No password to remember, rotate or reuse. No six-digit code arriving in an SMS that a SIM swap can intercept. No authenticator app with a QR code you photographed once and never thought about again. ## Why this is meaningfully more secure, not just more convenient Passkeys are public-key credentials bound to an origin. Three properties follow from that, and they are the whole argument. **Phishing stops working.** A passkey registered for `app.cmdz.com` will not present itself to `app-cmdz.com`, no matter how convincing the email was or how carefully the page was cloned. The browser makes that decision, not the person, and the browser is not tired at eleven at night. **There is nothing on our side worth stealing.** We store a public key. A breach of our database yields public keys, which are public. Compare that with any password database, where the value of the breach is proportional to how bad your users' password reuse is. **There is nothing to reuse.** The credential is unique per site by construction. Your cmdz passkey cannot be replayed anywhere, because it does not exist anywhere else. ## The part that is genuinely a trade-off If you have exactly one passkey and you lose the device holding it, you are locked out. That is real, and pretending otherwise would be the kind of thing this blog is supposed to avoid. Three answers, in order of how much we recommend them. **Register a second passkey.** This is the good answer. Most passkeys now sync through iCloud Keychain, Google Password Manager or 1Password, so "the device" is usually already "the account". Add a second one anyway — a hardware key in a drawer, or a second device — and the problem disappears. **Keep a recovery code.** A signed, single-use code you store yourself, offline. Using it lets you register a new passkey. It is a bearer credential, so treat it like one. **For teams: another owner.** An organisation with two owners has a recovery path that does not depend on either person's hardware. For anything with revenue attached, do this. ## Why there is no password fallback The obvious objection is: why not offer passwords for people who want them? Because an account is only as secure as its weakest available method. A password fallback means the phishing attack works again — the attacker simply asks for the fallback. Every property listed above evaporates, and what remains is a passwordless login screen with a password behind it, which is worse than either option chosen honestly. So no fallback, and no exception on request. If that is disqualifying for you, we would rather you know now. ## Step-up confirmation Some actions ask for your passkey again even though you are already logged in: changing payment details, deleting a project, transferring ownership, authorising an agent with a write profile. That is not friction for its own sake. A session token can be stolen; a fresh passkey assertion requires the device and the person. Anything that moves money or destroys data is worth one more touch. The admin interface goes further: an IP allowlist and a fresh passkey confirmation for anything that touches a customer account. Our own staff have a harder login than you do, which is the correct way round. ## Two domains, one reason The platform lives on `cmdz.com`. Customer applications live on `cmdz.app` — a different registrable domain, deliberately. That boundary is doing real work. It is the WebAuthn relying-party boundary and the cookie-scope boundary at the same time, which means an application running on `something.cmdz.app` can never see a platform session cookie and can never be offered a platform passkey. Even if that application is hostile. Even if it was written by a model at three in the morning and nobody read it. If those two things shared a domain, every customer app would be a potential credential-harvesting surface for the platform hosting it. Separating them costs us a second certificate and buys a category of attack that cannot happen. ## For agents An agent does not use a passkey — it uses an OAuth token you granted with a passkey, in your browser, at a moment you chose. It cannot bootstrap its own access, cannot register a passkey, and cannot manage members. Which means the answer to "what can an agent do to my account" starts with "nothing you did not personally authorise with a fingerprint", and that is a good place for the answer to start. ## 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) --- # Deploy a Next.js + Postgres app without writing a Dockerfile > The most common stack on this platform, end to end: detection, the database, migrations on release, environment variables, preview environments and what the whole thing costs. The most common stack on this platform, end to end: detection, the database, migrations on release, environment variables, preview environments and what the whole thing costs. 17 Jun 2026 · 4 min read · cmdz Next.js with Postgres is the single most common shape of application here. This is the whole path, including the parts that usually go wrong. ## Deploy first, configure later ```bash npx @cmdz/cli deploy ``` Detection reads `package.json`, your lockfile and `next.config.mjs` and works out the framework, the package manager and the Node version. If there is a `schema.prisma` or a `drizzle.config.ts` pointing at `postgresql`, it also works out that you need a database — and starts provisioning it in parallel with the build rather than after it. You do not write a Dockerfile. You may, and if one exists we use it, but the default path does not need it. ## The database If detection did not find it, or you want to be explicit: ```bash cmdz services create postgres --size small --attach web ``` It quotes before it creates: ``` instance 1 × small 2 credits/hour storage 5 GB 150 credits/GB/month backups 5 GB 10 credits/GB/month ────────────────────────────────────────── estimated 2 260 credits/month = € 2.26 after this your limit has € 5.34 of headroom left. create it? [y/N] ``` Showing the price before the thing exists is a house rule, not a courtesy. It applies to the CLI, the portal and the MCP tools equally. Attaching injects `DATABASE_URL` into the app. You never copy a connection string, and rotating the credential later does not require a redeploy. ## Migrations belong in the release command The mistake that costs people an afternoon is running migrations in the build. A build produces an image and may run many times, including for a preview environment you have forgotten about. A **release** command runs once per deploy, after the image is built and before traffic moves. ```toml [apps.web] release = "pnpm prisma migrate deploy" start = "pnpm start" ``` If the release command fails, the deploy fails and the previous version keeps serving. That is the behaviour you want: a failed migration should never be followed by a new app version talking to an old schema. ## Environment variables ```bash cmdz env set STRIPE_SECRET_KEY=sk_live_… --app web cmdz env set NEXT_PUBLIC_SITE_URL=https://linktree.dev --app web ``` Two things to know. Variables prefixed `NEXT_PUBLIC_` are baked into the client bundle at build time by Next.js, so changing one requires a rebuild, not just a restart. We trigger that for you, but it is worth knowing why the deploy took forty seconds instead of five. And `cmdz env pull` writes **names, never values**. That is true for you, for your CI, and for an agent. An agent that has to understand your app needs to know a `STRIPE_SECRET_KEY` exists; it has no business knowing what it is. ## Preview environments Connect the repository and every pull request gets its own URL and its own environment. By default a preview shares nothing with production: it gets its own database, seeded from your seed script rather than cloned from live data. You can point it at a shared preview database if you would rather, and for most apps you should not. Previews sleep when nobody visits and wake on the first request, so twenty open pull requests cost close to nothing. They are cleaned up when the branch is. ## Caching and ISR Next.js caching mostly works the way it does on your machine, with one difference worth knowing: with more than one replica, the in-memory cache is per replica. For anything that must be shared — ISR revalidation state, rate limit counters, sessions — attach Valkey and point the cache handler at it. ```bash cmdz services create valkey --size small --attach web ``` This is not a cmdz-specific problem; it is what happens anywhere you scale past one instance. It surprises people because it does not happen locally. ## Images Next.js image optimisation runs in your app, which means it uses your CPU and your memory. On a small instance a page full of unoptimised images is the most likely cause of a memory spike. Either pre-optimise at build time, or give the app a bit more memory and watch what it does to your run rate in the usage screen. Both are fine; guessing is not. ## The domain ```bash cmdz domains buy linktree.dev --attach web ``` Registration, zone, A and AAAA records and a certificate, in one command. The renewal price is shown before you confirm — not just the first-year price, because a cheap first year with an expensive renewal is a dark pattern and we are not doing it. Domains are charged on a card, outside your spending limit. That is deliberate: a paused workload should never be able to cost you a domain name. ## What it costs Two replicas at 0.5 vCPU and 1 GB, a small Postgres with 5 GB, daily backups, and a normal amount of deploying: ``` compute € 2.19 memory € 2.19 database € 1.46 storage € 1.05 backups € 0.07 build minutes € 0.08 outbound € 1.26 ──────────────────────── € 8.30 / month ``` Set your limit at € 15 and you have room for a bad week without having room for a bad month. Run it through [the calculator](/pricing#calculator) with your own numbers. ## 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) --- # Deploy Laravel on cmdz: Octane, migrations and queues > A real Laravel deployment: the release command, queue workers as their own workload, the scheduler, Octane, storage on object storage, and where the horizontal-scaling surprises are. A real Laravel deployment: the release command, queue workers as their own workload, the scheduler, Octane, storage on object storage, and where the horizontal-scaling surprises are. 10 Jun 2026 · 4 min read · cmdz Laravel is the second most common stack here and the one with the most moving parts, because a real Laravel app is rarely one process. ## The shape of a Laravel deployment Most Laravel apps are three workloads, not one: ```toml [apps.web] start = "php artisan octane:start --host=0.0.0.0 --port=8000" release = "php artisan migrate --force" [apps.worker] start = "php artisan queue:work --tries=3 --max-time=3600" type = "worker" [apps.scheduler] start = "php artisan schedule:work" type = "worker" ``` They share an image and an environment and scale independently. The web app scales with traffic; the worker scales with queue depth; the scheduler stays at exactly one replica, which matters more than it looks. ## Migrations run once, in release `release` runs once per deploy, after the build and before traffic moves. Not in the build — a build can run many times, including for previews. If `php artisan migrate --force` fails, the deploy fails and the current version keeps serving. A failed migration followed by new code against an old schema is the worst outcome available, and this ordering makes it impossible. For zero-downtime deploys, write migrations that are backwards compatible for one release: add a column before you write to it, stop reading a column before you drop it. That is ordinary practice anywhere with rolling releases, and it is worth saying because the alternative is discovering it during a rollout. ## The scheduler is exactly one replica `schedule:work` on three replicas runs your scheduled tasks three times. Keep it at one, and use `withoutOverlapping()` on anything long. If you would rather not run a scheduler process at all, the platform has native cron workloads that invoke an artisan command on a schedule. Fewer processes, same result, and the cost is per invocation rather than per idle minute. ## Queue workers ```bash cmdz scale worker --replicas 3 ``` Two settings people forget: `--max-time=3600` recycles the worker every hour, which keeps a long-running PHP process from accumulating memory. `--tries=3` bounds retries, so a poison job fails permanently instead of forever. Point the queue at Valkey rather than the database. It is what it is for, and the database connection you save under load is real. ```bash cmdz services create valkey --size small --attach web,worker ``` ## Octane Octane keeps the framework in memory between requests, and on a small instance the difference is large — bootstrapping Laravel is a meaningful fraction of a short request. It also changes the rules: static properties, singletons and anything you set on a service container survive between requests. Most apps are fine. Apps that hold request state in a singleton are not, and the bug looks like data from one visitor appearing for another, which is the kind of bug you want to find in staging. Deploy without Octane first, confirm the app is healthy, then switch the start command. Rolling back is one key if it goes badly. ## Storage goes to object storage `storage/app/public` on a local disk does not survive a redeploy and is not shared between replicas. Use the S3 driver: ```bash cmdz services create bucket --name uploads --attach web,worker ``` ```env FILESYSTEM_DISK=s3 ``` The credentials and endpoint are injected. Do not commit them. ## Sessions and cache With more than one replica, the `file` session driver means a visitor is logged in on one replica and not on another. Use `redis` for sessions and cache, pointed at the same Valkey. This is the single most common "it works locally" failure with Laravel on any platform that runs more than one instance. ## Logs Set `LOG_CHANNEL=stderr`. The platform collects stdout and stderr, indexes them and keeps seven days of runtime logs (build logs are kept for ninety days), searchable, and readable by your agent through `cmdz_get_runtime_logs`. Writing to `storage/logs/laravel.log` means the logs live on a disk that disappears with the container and are invisible to everything that could help you. ## Health checks Octane answers quickly, but the first request after a release still has work to do. Give the app a health route that touches nothing expensive: ```php Route::get('/up', fn () => response('ok')); ``` Laravel 11 and later ship this. The startup probe polls it every two seconds and traffic only moves once it answers. A health check that queries the database will make a slow database look like a broken deploy. ## What it costs Web at 2 × (1 vCPU, 1 GB), one worker at 0.5 vCPU, a scheduler at 0.25, a small Postgres, a small Valkey and 20 GB of uploads: ``` compute € 7.66 memory € 5.20 database € 1.46 valkey € 1.46 storage + bucket € 3.05 backups € 0.25 ──────────────────────────── € 19.08 / month ``` Outbound traffic is € 0.02 per GB, which for this app is a rounding error — and 7.5× less than the same gigabytes cost at Vercel or Render, which is where the surprise usually is. ## 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) --- # Deploy FastAPI with a vector database for RAG > A retrieval-augmented app end to end: FastAPI on Uvicorn, pgvector, where the embedding cost actually lands, and why the spending limit matters more for this shape of app than any other. A retrieval-augmented app end to end: FastAPI on Uvicorn, pgvector, where the embedding cost actually lands, and why the spending limit matters more for this shape of app than any other. 3 Jun 2026 · 3 min read · cmdz Retrieval-augmented apps are the shape most likely to produce a surprising invoice, because the expensive part is not the part you are watching. ## The app ```toml [build] runtime_version = "3.12" package_manager = "uv" [apps.api] start = "uvicorn app.main:app --host 0.0.0.0 --port 8000" ``` Detection handles most of this on its own from `pyproject.toml` and `uv.lock`. Pin the Python version explicitly anyway — a silent minor version change is the sort of thing that costs you a Tuesday. ## The vector store We run Postgres with `pgvector`, which for the overwhelming majority of applications is the correct choice over a dedicated vector database. One system to back up, one system to query, transactional consistency between your embeddings and the rows they describe. ```bash cmdz services create postgres --size small --extensions vector --attach api ``` The extension is enabled at creation. `DATABASE_URL` is injected. Vector index storage is metered separately at 200 credits per GB per month — € 0.20 — because an HNSW index is genuinely larger and more expensive to keep resident than an ordinary B-tree. A million 1536-dimension embeddings with an HNSW index is roughly 9 GB, so about € 1.80 a month. That is the honest number, and it is smaller than most people expect. ## Where the cost actually is Here is the part worth internalising: **the platform is not the expensive component in a RAG app.** For a typical document assistant, the monthly bill breaks down something like: - Your embedding provider, on ingestion and on every query - Your inference provider, on every answer - cmdz, for the compute and the storage The third line is usually the smallest by a wide margin. We are not going to pretend otherwise to make our own pricing page look more important. What our limit does for you is bound the *second-order* costs — the compute that runs the loop, the storage that accumulates, the workers that retry. If your ingestion job goes into a loop at three in the morning, the limit stops the compute. It cannot stop your embedding provider's meter, and no hosting platform can. Which is an argument for keeping the ingestion loop on the platform with the ceiling, and for putting your own budget check around the provider call. ## Ingestion is a job, not a request Do not embed documents inside an HTTP handler. Put it in a worker: ```toml [apps.ingest] start = "python -m app.worker" type = "worker" ``` ```bash cmdz scale ingest --replicas 0 # off between batches cmdz scale ingest --replicas 4 # on for the run ``` Scaling a worker to zero means it costs nothing while idle. For a workload that runs for two hours a week, that is the difference between € 0.40 and € 14 a month. ## The query path Two things that matter more than the model choice: **Cache the embeddings of queries.** The same question arrives repeatedly in any real application. Valkey with a hash of the normalised query as the key removes a provider call and about 200 ms. **Set a timeout on the provider call, and mean it.** A hanging inference call holds a worker, and enough of them hold every worker. Ten seconds and a clear error beats waiting. ## Health checks with a warm-up Loading a tokenizer or a local model at import time makes the first request slow. Answer the health check before that finishes: ```python @app.get("/health") def health(): return {"ok": True} ``` Keep it free of database and model access. A health route that queries pgvector turns a slow index into a failed deploy. ## Backups Daily, included, with point-in-time recovery, and restoring costs nothing. That covers both your rows and your embeddings, which is the thing a separate vector database would have made into two problems. Re-embedding a corpus because you lost the index is a real cost with a real invoice attached, and it is the sort of thing that only becomes obvious afterwards. ## What it costs Two API replicas at 0.5 vCPU and 1 GB, a small Postgres with pgvector, 9 GB of index, 20 GB of documents, and an ingestion worker that runs two hours a week: ``` compute (api) € 2.19 memory (api) € 2.19 ingest worker € 0.36 database € 1.46 storage 20 GB € 3.00 vector index 9 GB € 1.80 backups € 0.29 ──────────────────────────── € 11.29 / month ``` Set a limit that covers a bad ingestion run. Then set a separate budget with your embedding provider, because that one is not ours to cap. ## 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) --- # Choosing a region: data residency and your own redundancy > What a region actually guarantees, what it does not, and how to run one app in two of them — including the honest limits of what we promise across regions. What a region actually guarantees, what it does not, and how to run one app in two of them — including the honest limits of what we promise across regions. 27 May 2026 · 4 min read · cmdz A region here is a physical location: a rack or hall with its own power, network and cooling path. Not an availability zone abstraction, not a logical grouping. Somewhere you could, in principle, drive to. ## What choosing one guarantees Your app, its databases, its volumes, its backups and its logs live in that region and do not leave it. Not for a failover, not for a maintenance window, not for a batch job that seemed convenient. That last point is where a lot of "EU region" claims get soft. A control plane in another jurisdiction, logs shipped somewhere central, backups replicated to whichever bucket was cheapest — all of that is common and all of it undermines the answer you give when a customer asks where their data is. Ours does not do it. ## Choosing is per environment Not per account. Production in Rotterdam and staging in Frankfurt is an ordinary configuration, and the region appears on the environment, the app, the database, the backup and the invoice line. You should never have to go looking for where something lives. ## What we handle, and what we do not **Within a region we handle high availability.** Multiple nodes, at least two replicas, database failover, replicated block storage. A node dying is our problem and you should not notice it. **Across regions, redundancy is yours to arrange.** We give you the building blocks: - per-region environments of the same project - health-driven DNS, so a region that stops answering leaves the rotation - cross-region read replicas for Postgres **What we do not promise is automatic, seamless multi-region failover.** Not in this version. That is a hard problem with real consistency trade-offs, and a platform that claims it casually is either doing something narrower than it sounds or has not been tested by an outage yet. We would rather write that sentence on the website than have you discover it on a bad afternoon. ## Running one app in two regions ```bash cmdz env create production-fra --region de-fra-1 cmdz deploy --env production-fra cmdz db replica add --from nl-rtm-1 --to de-fra-1 cmdz domains health-dns linktree.dev --targets nl-rtm-1,de-fra-1 ``` Four commands. What you get: - Two independent copies of your app, in two failure domains. - DNS with health checks; a failing region leaves the rotation in about thirty seconds. - A read replica in the second region, with visible replication lag. What you should be clear-eyed about: **writes still go to the primary region.** If Rotterdam goes down, the Frankfurt copy serves reads immediately and writes need a promotion, which is a deliberate operation. Synchronous multi-region writes are not something we offer, and if that is your requirement, we are not your platform for it. ## The cost Roughly double the compute, plus the replica. For the Next.js app from an earlier post — about € 7 a month single-region — a two-region setup lands around € 15. Whether that is worth it depends entirely on what an hour of downtime costs you, and that is a number you know and we do not. Run it through [the calculator](/pricing#calculator) before you decide. ## Which region to pick **Rotterdam (`nl-rtm-1`)** is the default and the flagship. Pick it unless you have a reason not to. **Amsterdam (`nl-ams-1`)** is the second Dutch region — the natural pair for a two-region setup that stays entirely inside one jurisdiction. **Frankfurt (`de-fra-1`)** is the German region. Still EEA, and a genuinely separate failure domain from either Dutch site. London, New York and Singapore are on the roadmap and are listed as **planned**, not as coverage. A region that does not exist yet is not a feature, and we are not going to draw a dot on a map that implies otherwise. If you have latency-critical users in Asia today, we are honestly not the right choice yet. Better to hear that here than from a latency graph. ## Residency and the paperwork Choose an EU region and your data — including backups and logs — stays in the EEA. The [data processing agreement](/dpa) names the data center and the supplier per region, and you can read it on this site without giving anyone an email address. If you deliberately choose a region outside the EEA once we have one, that choice is an instruction under the DPA and we will tell you what it implies rather than let it happen quietly. ## Price per region Power, hardware and connectivity differ per location, so the price book can carry a small per-region factor. You see the price for your region before you create anything. The ceiling behaves identically everywhere. That is not region-dependent and it never will be. ## 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) --- # Buy a domain and manage DNS in one place > Search, buy, attach and certify in one flow — plus why domains are the one thing charged outside your spending limit, and why we always show the renewal price. Search, buy, attach and certify in one flow — plus why domains are the one thing charged outside your spending limit, and why we always show the renewal price. 20 May 2026 · 3 min read · cmdz Buying a domain and pointing it at an app is four systems in most setups: a registrar, a DNS provider, a certificate authority and your hosting. Here it is one command. ```bash cmdz domains buy linktree.dev --attach web ``` That registers the name, creates the zone, writes the A and AAAA records, requests the certificate and puts the app behind it. About ninety seconds, most of which is the registry. ## Search first ```bash cmdz domains search linktree ``` ``` linktr.ee taken linktree.dev € 14.38/yr · renews € 14.38 linktree.app € 16.75/yr · renews € 16.75 linktree.nl € 10.20/yr · renews € 10.20 ``` Notice the second column. ## Why the renewal price is always shown The registrar industry runs on a specific pattern: a first year at € 1, a renewal at € 45, and a checkout flow that only shows you the first number. It is legal, it is common, and it is a dark pattern. We show both, always, in the search results, in the confirmation, and in the portal. If a name has an expensive renewal you will know before you commit, not eleven months later. Our margin is a flat 25% over the registry cost, in euros, converted daily. No introductory pricing, no loss-leader first year, no upsell for the WHOIS privacy that should be standard — it is on by default, at no charge, for the extensions that support it. ## Why domains are outside your spending limit This is the one exception to the ceiling, and it deserves an explanation rather than a footnote. A domain registration is a **purchase**, not a metered resource. The registry charges us the moment you confirm, and the name is yours for a year whatever happens afterwards. If domains were inside the limit, then hitting the limit could cause a renewal to fail, and a failed renewal costs you the domain. That is a worse outcome than a separate charge on a card — considerably worse, because a lapsed domain can be caught by a squatter within minutes and is often unrecoverable. So: charged separately, immediately, on a card, with the price shown before you confirm. Renewals are charged 30 days before expiry, with a reminder, and you can turn auto-renew off. ## DNS is ours Not a wrapper around someone else's API. Authoritative nameservers we run, with an editable zone: ```bash cmdz dns add linktree.dev MX 10 mx1.provider.tld cmdz dns add linktree.dev TXT "v=spf1 include:provider.tld -all" cmdz dns list linktree.dev ``` Three things that come from running it ourselves rather than proxying: **Zone versioning.** Every change is a version. A bad edit at midnight is one `cmdz dns rollback` away from undone, which is a materially different experience from trying to remember what the old record said. **Templates.** The records people always forget — SPF, DMARC, MTA-STS, the CAA record that stops another CA issuing for your domain — are one command each, with sane defaults. **Health-driven records.** Multiple A and AAAA records with health checks, so a region that stops answering leaves the rotation. This is how you build your own cross-region redundancy. ## Certificates Issued automatically, renewed automatically, wildcards included, at no charge. There is no certificate line item because there is no certificate price. If you point a domain you own elsewhere at us, add the records we show you and the certificate is issued once they propagate. If you use Cloudflare in front, that works too — it is listed as a subprocessor in the DPA precisely because it is your choice to route through them, not ours. ## Transferring a domain in ```bash cmdz domains transfer linktree.dev --auth-code XXXX ``` The transfer adds a year to the registration, as registry rules require. We show the price for that year before you start. ## What we will not do We will not sell you hosting-adjacent add-ons at checkout. No "SSL certificate" upsell for something included, no "premium DNS" for what is already the DNS, no "domain protection" for the transfer lock that should always be on. A registrar business built on those upsells makes its money from people who do not know what they are buying. That is not a business we want, and it is not compatible with the rest of this platform. ## 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) --- # Preview environments per pull request, explained > What gets created, what is shared with production and what is not, how sleeping keeps twenty of them nearly free, and the two mistakes that make previews expensive. What gets created, what is shared with production and what is not, how sleeping keeps twenty of them nearly free, and the two mistakes that make previews expensive. 13 May 2026 · 4 min read · cmdz A preview environment is a full copy of your application, on its own URL, for one branch. Open a pull request and it appears; merge or close it and it goes away. The reason to care is not the demo. It is that reviewing a diff tells you whether the code is plausible, and clicking the thing tells you whether it works. ## What gets created For every pull request: - Your app, built from that branch, in its own micro-VM - A URL: `pr-241-linktree.cmdz.app`, with a certificate - Its own environment variables, inherited from a preview set you control - Its own database, if the app has one That last item is the important default. A preview does **not** get a connection to your production database. It gets its own, seeded from your seed script. That is deliberate and occasionally inconvenient. The alternative — previews pointed at live data — means a migration in an unmerged branch can alter production, and a debug endpoint someone added at two in the morning can read real customer records from a URL that is not behind your auth. We would rather you opt into that explicitly than inherit it. ## What is shared, and what is not | | Production | Preview | |---|---|---| | Application code | main | the branch | | Database | production | its own, seeded | | Object storage | production bucket | its own bucket | | Environment variables | production set | preview set | | Secrets | production values | preview values you set | | Domain | yours | generated | You can override any of it. If a preview genuinely needs to talk to a shared staging database, point it there — just do so on purpose. ## Sleeping is what makes this affordable A preview with no traffic scales to zero after a few minutes of inactivity and wakes on the first request. The wake takes a second or two for most apps. The cost consequence is large. Twenty open pull requests, each awake maybe an hour a day between the author, a reviewer and a designer, bill about 4% of a month each. Twenty previews cost roughly what one always-on instance costs. Which means the honest advice is: do not ration them. A preview per pull request is the point. ## The two ways previews get expensive **A preview with a background worker that never idles.** A queue worker polling every second is never inactive, so it never sleeps, so twenty previews are twenty always-on workers. Either exclude workers from previews or give them a longer poll interval there. ```toml [apps.worker] preview = false ``` **A large database per preview.** A small Postgres is € 1.46 a month; twenty of them is € 29. If your seed data is large, share one preview database across previews with a schema per branch, or seed less. Both are visible in the usage screen broken down per environment, so you will see it before the invoice does. And either way, the ceiling still holds. ## Migrations in previews The release command runs in a preview exactly as it does in production, which is the whole value: you find out that your migration fails on a fresh database *before* it runs on the real one. If it fails, the preview deploy fails and the pull request gets the error. That is a much better place to learn it than production. ## The invoice preview A comment on the pull request with what this change does to your monthly run rate: ``` cmdz · preview pr-241 ✓ https://pr-241-linktree.cmdz.app cost impact of this branch, if merged: compute +€ 1.10/mo (worker replicas 1 → 2) storage unchanged ────────────────────────────────────────── run rate € 7.04 → € 8.14/mo limit € 15.00 · 54% used ``` Knowing that a change costs money at review time is worth considerably more than knowing it at the end of the month. This is also available to your agent through `cmdz_explain_cost`, which means "what will this cost" is a question you can ask the thing that wrote the branch. ## Cleanup Merging or closing the pull request removes the preview, its database and its bucket within minutes. A branch that has had no commits for thirty days is cleaned up too, after a warning, because everybody has a `fix-the-thing-2` branch from March. ## Sharing them Preview URLs are public by default — reviewers, designers and clients should not need an account. If your app is pre-launch and you would rather not have it indexed or found, turn on basic authentication for previews with one setting; the credentials appear in the pull request comment. Search engines are excluded from preview hostnames regardless. ## 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) --- # What counts toward your limit — and what does not > The complete list, both columns, including the two things outside the ceiling and the reason for each. No "and more", no asterisks. The complete list, both columns, including the two things outside the ceiling and the reason for each. No "and more", no asterisks. 6 May 2026 · 3 min read · cmdz A ceiling is only as good as the list of what it covers. So here is the whole list, both columns, with the reasoning. ## What counts **Compute.** Per vCPU minute, on what you allocate rather than what you happen to use. Allocating two vCPU and using one costs two, because we reserved two for you and cannot sell them to anyone else. **Memory.** Per GB minute, same principle. **Storage.** Per GB month on the allocated volume size, sampled every five minutes. Growing a volume mid-month is charged from the moment it grows. **Object storage.** Per GB month plus a small charge per ten thousand operations. Both are metered from the storage layer directly, and we subtract delete markers rather than billing you for them. **Managed databases.** Per instance hour while running or degraded. A paused instance does not count, which makes pausing a real cost lever for staging environments. **Backups.** Per GB month, measured **after** compression, so you pay the smaller number. Restoring costs nothing at all — a restore fee is a fee for having a bad day, and we are not charging it. **Vector indexes.** Per GB month, separately, because an HNSW index is genuinely more expensive to keep resident than an ordinary index. **Build minutes.** Per minute of build. Queue waiting time does not count; you should not pay for our capacity planning. **Static requests.** Per million, for static workloads only. A server-rendered app is billed on its compute instead, not both. **Transactional email.** Per accepted message. Rejected messages cost nothing. **Dedicated IPv4.** Per month, and only if you ask for one. Shared IPv4 and IPv6 are included. ## What does not count **HTTPS certificates.** Requested and renewed automatically, wildcards included. **Extra domains on an app.** As many as you like. Render charges $0.25 per domain per month; we think charging for a DNS record and a certificate that cost us nothing is hard to justify. **Extra team members.** No per-seat price, on any plan. Vercel charges $20 per additional paid seat. A pricing model that makes you think twice about adding a colleague to a project is a pricing model working against the product. **Log retention.** 7 days of runtime logs and 90 days of build logs, searchable. **Metrics.** Thirteen months of history, so you can compare this month with the same month last year. **DDoS protection, HTTP/3, IPv6.** Standard on every workload. **The MCP server and all 47 tools.** Not an add-on, not a tier. **Support.** Included on every plan, including the free one. ## The two things outside the ceiling **Domain registrations and renewals.** A registration is a purchase from a registry, not a metered resource — the registry charges us at the moment you confirm and the name is yours for a year. If domains sat under the limit, hitting the limit could cause a renewal to fail, and a failed renewal costs you the domain, which is a far worse outcome than a separate charge. Billed on a card, at cost plus a flat 25%, with the renewal price shown before you confirm. **VAT.** The ceiling is on the amount excluding VAT. VAT is added according to your tax status, because that is not ours to cap. That is the complete list of exceptions. There is no third one. ## Rounding, and which way it goes All intermediate calculation happens in high-precision decimals and rounds to whole credits exactly once, when the line is written to the ledger, per metric per day. Where measurement is imprecise, the imprecision favours you by design: - CPU during the first fifteen seconds after a pod starts is not counted. - Storage growth within a five-minute window is only seen at the next sample. - Backups are measured after compression. - Requests blocked at the edge never reach us and never count. These are small amounts. We are listing them because a pricing page that only describes the favourable rounding is not a pricing page. ## Seeing where it went ```bash cmdz usage --breakdown metric cmdz usage --breakdown endpoint cmdz usage --diff 41 42 ``` Per metric, per endpoint, and the difference between two deployments. Your agent can read all three through `cmdz_explain_cost`, which is what makes "why did this get more expensive" a question with an answer rather than a theory. The full price book with an amount next to every line is on [the pricing page](/pricing). ## 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) --- # cmdz vs a hyperscaler: cost predictability for AI builders > Three concrete workloads priced against the published rates of Vercel, Railway, Render, Fly and Cloudflare — including the two profiles where they win. Three concrete workloads priced against the published rates of Vercel, Railway, Render, Fly and Cloudflare — including the two profiles where they win. 29 Apr 2026 · 4 min read · cmdz Comparisons written by a vendor are worth exactly as much as their willingness to lose. So: three workloads, public rates from July 2026, and the cases where we lose. ## Workload A — the side project A Next.js app with a small Postgres. Ten thousand visitors a month, about 60,000 requests, maybe 20 GB out. | | Monthly | |---|---| | **cmdz** | **€ 7.46** | | Railway | ~$12 (Hobby $5 + usage + $1 egress + database) | | Render | ~$32 (Standard $25 + database $7) | | Vercel | ~$20 (Pro seat; database from a marketplace partner, billed separately) | | Fly.io | ~$9 (two shared-cpu machines + volume + egress) | | Cloudflare | ~$5 (Workers Paid; D1 within free limits) | **Cloudflare wins this one**, if your app fits the Workers model. If you wrote a Next.js app with a Node runtime and a Prisma client, it does not fit without a rewrite, and "rewrite it into isolates" is not a price comparison. Fly is close to us and genuinely comparable on isolation. The difference is the ceiling, not the number. ## Workload B — the app with revenue Laravel with a queue worker, a scheduler, Postgres, Valkey and 20 GB of uploads. 100,000 visitors, about 600,000 requests, 180 GB out. | | Monthly | |---|---| | **cmdz** | **€ 22.68** | | Railway | ~$48 (usage + $9 egress + two databases) | | Render | ~$64 (two instances + database + key-value + $12 egress) | | Vercel | ~$45 (Pro + functions; Laravel is a poor fit regardless) | | Fly.io | ~$34 (four machines + volumes + $3.60 egress) | | Cloudflare | not applicable (no long-lived PHP process) | We win this profile, and the reason is mostly the two managed services and the absence of an egress line. ## Workload C — the one that goes viral Workload B, on the day a post lands. Traffic × 40 for three days: 2.4 TB out, compute peaking at four times normal. | | That month | |---|---| | **cmdz, € 40 of credit** | **€ 40.00** (ran out on day 25) | | **cmdz, € 100 of credit** | **€ 79.20** (never ran out) | | Railway | ~$120 (egress alone $120 at $0.05/GB) | | Render | ~$310 ($0.15/GB beyond the allowance) | | Vercel | ~$260 (Fast Data Transfer beyond 1 TB) | | Fly.io | ~$82 ($0.02/GB) | | Cloudflare | ~$14 (no egress charge) | This is the whole argument on one line. On the day it matters, our number is either the actual usage or the number you chose in advance — and never anything else. Note the two cmdz rows. 2.4 TB of egress is € 48 of the € 79.20 — real money, and the honest reason we are not "free egress". It is also € 312 less than Render would charge for the same traffic. With € 40 of credit the month costs exactly € 40 and the apps paused; with € 100 it costs what it used. Both outcomes are ones you selected in advance. Cloudflare is dramatically cheapest here. Again: only if your app is already isolates. ## Where they are better than us This section is not decoration. **Cloudflare is cheaper than us at volume, and charges no egress.** Nothing VM-based will beat isolates on cost per request. If your app already fits that model, use it. **Vercel's Next.js developer experience is better than ours.** Preview deployments, image optimisation, ISR, the toolbar — years of depth in one framework. We do not win on Next.js depth and we are not going to claim we do. **Fly.io has our isolation quality and global placement.** Firecracker versus Kata is a distinction without a practical difference. They have regions we do not. **Railway has a real hard limit and the best writing MCP in the field.** They are the most dangerous competitor we have. Their limit has a $10 minimum and hitting it takes workloads offline, which they describe as possibly destructive; ours starts at € 0 and pauses rather than terminates. That is a difference of degree, not of kind, and we are not going to pretend it is a difference of kind. **Heroku's add-on ecosystem and Postgres tooling are richer than ours.** Their MCP can do `pg_outliers` and `pg_locks`. We have `cmdz_run_sql` and backups. **Coolify on your own hardware is cheaper than us, full stop.** If you have the time and the knowledge, you should do that. We sell the time and the knowledge, not the servers. ## What we actually claim Not "cheapest". Three things: 1. **Predictable.** The invoice cannot exceed the number you set. On any other platform in this table except Railway and Netlify, it can. 2. **Egress at € 0.02/GB.** Not free — we would rather charge for it than pretend — but 7.5× cheaper than the € 0.15 that Vercel and Render charge, which is where most of the difference in the tables above comes from. 3. **Operable by your agent.** 47 tools with write access, bounded by that same ceiling — which is what makes handing over the keys a reasonable thing to do rather than a brave one. If predictability is not worth anything to you and your traffic is flat and you have the time, Coolify on a Hetzner box is the correct answer and we will not be offended. ## Method Public rates from provider documentation, July 2026. Egress estimated at 350 KB average per request. Every figure is an estimate that depends on assumptions about your traffic; run yours through [the calculator](/pricing#calculator), which will also tell you when they are cheaper than us. Something out of date? Email us. We will correct it, including when the correction is to our disadvantage. ## 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) --- # EU data, EU law: what sovereignty actually means for your stack > Beyond the region dropdown: where the control plane lives, where the logs and backups go, who the subprocessors are, and which questions to ask any provider claiming an EU region. Beyond the region dropdown: where the control plane lives, where the logs and backups go, who the subprocessors are, and which questions to ask any provider claiming an EU region. 22 Apr 2026 · 4 min read · cmdz "We have an EU region" is a sentence that does less work than most people assume. Here are the questions that actually determine the answer, and ours. ## Question 1: where does the control plane live? Your workload can run in Frankfurt while the system that manages it — the API, the database of what should be running, the audit log — runs somewhere else entirely. That control plane holds your account data, your project names, your environment variable **names**, your usage history and your invoices. An EU region with a US control plane means your metadata is subject to a different jurisdiction than your data, and metadata is often the sensitive part. **Ours:** the control plane runs on our own hardware in the Netherlands. It is the same infrastructure as everything else, not a separate managed service somewhere convenient. ## Question 2: where do the logs go? Logs are the most commonly overlooked path out of a jurisdiction. They contain request paths, IP addresses, user identifiers, error payloads with real values in them. Many platforms ship logs to a central aggregation service in whichever region the vendor's contract points at. **Ours:** logs stay in the region of the workload that produced them. There is no central aggregation elsewhere. ## Question 3: where do the backups go? The second most commonly overlooked path. A backup is a complete copy of your database, and "replicated for durability" often means "replicated to wherever object storage was cheapest". **Ours:** backups stay in the region. Our own control-plane snapshots go off-site — deliberately to a *different* region than the one they describe, because a backup in the same failure domain is not a backup — and those are our operational data, not your customer records. ## Question 4: who are the subprocessors, per region? Not a generic list. Which ones touch data in *your* region, and what for. **Ours,** with what each one sees: - **Mollie** (Amsterdam) — payment processing. Sees payment identifiers, not your application data. - **WeFact** — invoicing. Sees your billing details. - **Openprovider / Hosting Concepts** — domain registration. Sees registrant details, as registry rules require. - **Cloudflare** — only if *you* enable it for your own domain. Your choice, listed because it is a real path. - **A transactional email provider** — for mail your app sends. - **The data center per region** — physical hosting of hardware we own. That is the whole list. It is in the [DPA](/dpa) and it changes with advance notice, not quietly. ## Question 5: is the legal counterparty in the EU? If your contract is with an entity in another jurisdiction, that jurisdiction's law reaches your relationship regardless of where the servers are. That is what the Schrems litigation was about, and it did not stop being true because everyone got tired of talking about it. **Ours:** the contracting entity is a Dutch B.V. Disputes go to a court in Rotterdam. Dutch and EU law, without a chain of intermediate agreements. ## Question 6: can you read the DPA before signing up? If a data processing agreement requires a sales conversation, that is a signal about how the company thinks about the document. **Ours:** [right here](/dpa), as an ordinary page. Read it, copy it, send it to your counsel. No form, no email address, no gated PDF. ## What sovereignty does not mean Some honesty in the other direction, because this topic attracts more marketing than it deserves. **It does not mean immunity from every legal process.** A Dutch company receives Dutch and EU legal orders and complies with them. What it means is that the process is one you can read about in a law you can look up, with a court you could go to. **It does not automatically mean better security.** A badly-run EU host is worse than a well-run American one. Jurisdiction is one property; competence is another, and they are independent. **It does not mean you have no obligations.** You are the controller for the data in your app. Where it lives is one of your decisions; what you do with it is the rest of them. **It is not automatically the most important criterion.** If your users need low latency in Asia today, our answer to that is worse than a hyperscaler's, and no amount of jurisdictional cleanliness changes it. ## Why we can answer these at all Because we own the hardware. Every question above has an awkward answer when the honest response is "our provider's provider handles that". We can say where the disk is, because we bought it. That is the same fact that makes [the spending ceiling](/hard-limit) possible, which is not a coincidence — it is one decision with two consequences. ## Ask your current provider The six questions, in order. The answers are usually findable in ten minutes of documentation, and the interesting part is not any single answer but which ones they make hard to find. ## 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) --- # Scaling to zero and back: how cold starts work > What actually happens between a request arriving at a sleeping app and it being served, where the milliseconds go, and when scale-to-zero is the wrong choice. What actually happens between a request arriving at a sleeping app and it being served, where the milliseconds go, and when scale-to-zero is the wrong choice. 15 Apr 2026 · 4 min read · cmdz A sleeping workload costs nothing. Waking one costs a moment. This post is about exactly how long that moment is, what it is made of, and when you should refuse the trade. ## What "asleep" means here A micro-VM that has been idle past its threshold is stopped, not deleted. The image stays on the node. The volume stays attached. The DNS record and the certificate are untouched. What stops is the compute meter, which is the entire point. ## The wake path A request arrives at the edge for a sleeping workload: ``` edge receives request 0 ms route lookup: workload asleep 1 ms request held; wake signal 2 ms micro-VM boots 90 ms process starts 200–2000 ms ← your app startup probe answers +0 ms request released to app ``` The micro-VM boot is about ninety milliseconds and it is not the variable. **Your process start is the variable**, and it varies by two orders of magnitude depending on what you wrote. The request is held, not rejected. The visitor sees a slow page, never an error. ## Where your milliseconds go Rough figures from real applications here: | | Process start | |---|---| | Go binary | 15–40 ms | | Static file server | 20 ms | | Node, small Express app | 120–300 ms | | Next.js production server | 400–900 ms | | Laravel with Octane | 300–600 ms | | Laravel without Octane | 600–1200 ms | | Python with a large ML import | 2000–8000 ms | That last row is where scale-to-zero stops being free. If you import torch at module level, your cold start is dominated by an import, and no amount of platform tuning helps. ## Making cold starts smaller **Import lazily.** Move expensive imports inside the function that needs them. A health check that returns `{"ok": true}` without importing your model turns an eight-second cold start into a two-hundred-millisecond one for everything that is not an inference request. **Do not connect to the database at startup.** Connect on first use, with a pool that fills lazily. An app that blocks its boot on a database handshake has added the database's latency to every cold start. **Do not run migrations at startup.** They belong in the release command, which runs once per deploy. An app that migrates on boot migrates on every wake. **Keep the image small.** Not because we charge for it, but because a smaller image is a smaller page cache to warm. ## When not to use it Three cases where always-on is correct: **Production apps with real users.** The first visitor of every quiet period pays the cold start. If that is a customer, you are optimising your infrastructure bill by spending their patience. **Anything with a hard latency budget.** A webhook receiver with a three-second timeout on the sender's side will eventually miss one. **Workloads with expensive warm-up.** If your app spends four seconds building an in-memory index at boot, sleeping throws that away every time. For those, use a **schedule** instead of an idle threshold: ```toml [apps.web.sleep] mode = "schedule" awake = "Mon-Fri 07:00-20:00 Europe/Amsterdam" ``` Awake for the hours people use it, asleep the rest. A business application that nobody touches at night bills about 40% of a month, and no user ever meets a cold start. ## Where it is obviously right **Preview environments.** This is the case the feature exists for. Twenty pull request previews, each genuinely used for an hour a day, cost roughly what one always-on instance costs. Ration them and you have optimised the wrong thing. **Staging and demo environments.** Awake when someone looks at them. **Internal tools.** The admin panel three people use twice a week does not need to run for 720 hours a month. **Batch workers.** Scale to zero between runs, up to four during them. A worker that runs two hours a week costs € 0.40 instead of € 14. ## Interaction with the limit Sleeping is one of the strongest levers you have for staying under a ceiling, and it is the one people reach for last. If you are at 80% of your limit on the twentieth of the month, putting staging and previews to sleep usually buys back enough headroom to finish the month without pausing production. The usage screen breaks cost down per environment, so you can see exactly which ones to put to sleep rather than guessing. Your agent can do this too — `cmdz_pause_app` is in the `build` profile, and "we are at 80%, pause everything that is not production" is a reasonable instruction to give something that has read your usage breakdown. ## 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) --- # Rollbacks in seconds: the 90-day deploy history > Why a rollback here is a cutover rather than a rebuild, what it does and deliberately does not undo, and how to make your migrations rollback-safe. Why a rollback here is a cutover rather than a rebuild, what it does and deliberately does not undo, and how to make your migrations rollback-safe. 8 Apr 2026 · 3 min read · cmdz A rollback that rebuilds is not a rollback. It is a deploy of older code, at deploy speed, at the worst possible moment. ```bash cmdz rollback ``` Six seconds, typically. Here is why. ## Why it is fast Every deploy is stored as an image digest plus the configuration that went with it. That image already built successfully and already passed its health check — those facts are recorded, not assumed. A rollback starts that exact image again and moves traffic once it answers. No build, no dependency resolution, no registry pull if the node still has the layers. It is a cutover. Ninety days of history, so `cmdz rollback --to 388` works for something from March. ## What a rollback undoes - The application code, exactly, byte for byte - The runtime configuration that shipped with it: replica count, instance size, start command - The routing, once the old version is healthy ## What it deliberately does not undo This is the part worth reading twice. **Your database schema.** A rollback does not reverse migrations. It cannot, safely: a down-migration that drops a column destroys data the new version already wrote, and a platform should never do that automatically. **Your data.** Obviously, but worth stating. **Environment variables you changed since.** Those are state, not code. **Anything an external system did.** Emails are sent. Webhooks are delivered. Payments are captured. So: a rollback restores your application. It does not restore the world. ## Making migrations rollback-safe The practice that makes this work is expand-and-contract, and it costs one extra deploy. Instead of renaming a column in one release: 1. **Expand.** Add the new column. Write to both. Deploy. This release is compatible with the previous one. 2. **Migrate.** Backfill. Read from the new column. Deploy. 3. **Contract.** Stop writing the old column. Drop it. Deploy. Between each step you can roll back one release without the schema being wrong. Between step one and two you can roll back freely. The rule of thumb: **any single deploy should be reversible without a schema change.** If it is not, split it. ## Automatic rollback You can arm it: ```toml [apps.web.rollout] auto_rollback = true error_threshold = "5% over 2 minutes" ``` The platform watches the error rate after a release. Cross the threshold and it cuts back to the previous version and tells you. This is a good default for a production app with real traffic, and a bad default for something with three visitors a day, where 5% is one request and one request is noise. ## The confidence this buys The real value is not the rollback. It is that a fast, reliable rollback changes how you deploy. Teams that fear deploying batch changes up, which makes each deploy larger, which makes each deploy riskier, which increases the fear. The loop is well documented and every engineer has lived in it. Six-second rollbacks break it. You ship the small thing on a Thursday afternoon, because if it is wrong you will know in two minutes and it will be gone in six seconds. That is worth more than any individual feature on this platform, and it is worth more the more of your code was written by something that types faster than you can read. ## For agents `cmdz_rollback` is in the `build` profile, which means an agent can roll back but cannot delete. That asymmetry is deliberate: rolling back is a recovery action and should be as available as possible; deleting is not. "The error rate spiked after the last deploy, roll it back and tell me what changed" is a reasonable thing to ask something that can read your metrics, your deploy history and your diff. It is also, notably, the three-in-the-morning scenario that made people want agent access in the first place. ## 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) --- # Metering explained: how usage becomes credits > The full chain from a 15-second sample to a line on your invoice: what we measure, how precise it is, which way the imprecision points, and why rounding happens exactly once. The full chain from a 15-second sample to a line on your invoice: what we measure, how precise it is, which way the imprecision points, and why rounding happens exactly once. 1 Apr 2026 · 4 min read · cmdz A spending limit is only trustworthy if the number it compares against is trustworthy. So here is the whole metering chain, including the parts that are imprecise and which direction the imprecision favours. ## The chain ``` [1] scrape every 15 s kubelet, cAdvisor, Traefik, MinIO, CNPG [2] rollup every 60 s 15 s samples → 60 s grains [3] price every 60 s grains → credits, display-unit formula [4] book every 60 s → credit_ledger, atomic += on spend_caps [5] reserve on demand before anything expensive starts ``` End to end, from a CPU second being consumed to it counting against your limit, is under two minutes. ## What we measure, and how **CPU** from the kubelet's cumulative counter, using `increase()` so a container restart does not read as a spike. Precision about ±1%. The first fifteen seconds after a pod starts are not counted, which favours you. **Memory** from the allocated limit, not the working set. This is exact, because it is a configuration value rather than a measurement. You are billed for what was reserved for you, because we could not sell it to anyone else. The working set is graphed alongside it so you can see how much room you are wasting. **Storage** from the volume's allocated capacity, sampled every five minutes and interpolated to the minute. Growth inside a five-minute window is only seen at the next sample — up to five minutes free, which favours you. **Object storage** from the storage layer's own usage metric, with delete markers subtracted. Without that subtraction you would be billed for the tombstones of files you deleted, which would be indefensible. **Requests** from the edge access log, one count per completed HTTP response. Requests blocked before they reach us never count. **Database instance hours** from the cluster status. `running` and `degraded` count; `paused` and `provisioning` do not. **Build minutes** from the builder, wall clock from start to finish. Queue time is excluded. ## Which way the imprecision points Every measurement has error. Ours points the same direction, on purpose: | Metric | Precision | Who it favours | |---|---|---| | CPU | ±1% | you (first 15 s free) | | Memory | exact | — | | Storage | exact at sample | you (up to 5 min of growth free) | | Object storage | ±0.5% | you (delete markers subtracted) | | Backups | ±1% | you (measured after compression) | | Requests | exact | you (blocked requests excluded) | This is not generosity. It is that a metering system whose errors favour the vendor is a metering system nobody should trust, and we would rather give up a fraction of a percent than have that argument. ## Credits, and why they exist One thousand credits is one euro, exactly, always. The reason for the unit is readability. A vCPU minute costs 0.05 credits — € 0.00005. An invoice denominated in euros at that scale is a wall of leading zeros, and every usage table becomes an exercise in counting decimal places. Every item is shown in both units on [the pricing page](/pricing), so nobody has to translate. ## Rounding happens exactly once This is the subtle part and it is where a naive implementation quietly overcharges. Each metric has a **display unit** — a GB month, a vCPU minute, a million requests — and a price per display unit. The bookable cost is: ``` cost = max(quantity_in_display_units − included, 0) × price_per_display_unit ``` computed in high-precision decimals, and **rounded to whole credits exactly once**, when the line is written to the ledger, per metric per day. The tempting alternative is to precompute a per-sample unit price and multiply. That is faster, and it is wrong: at nine decimal places the per-sample price for something like egress rounds up by about 2%, and multiplying by a large sample count turns a rounding artefact into a real amount — in our favour, which makes it exactly the kind of bug that never gets reported. So the display-unit formula is normative for every monetary booking. The per-minute figure you see in the live graph is calculated the fast way and is explicitly indicative. ## Reservations Booking tells you what already happened. **Reservations** are what makes the limit hard. Before an expensive operation starts — a build, a database, a scale-up — the platform reserves the credits it expects to need: ``` remaining = cap − used − reserved if remaining < 0: refuse ``` in the same transaction that would otherwise permit it. The reservation is released when the operation finishes and the real cost is booked. This is why the ceiling is a ceiling rather than an alarm: the check is in the path, not on a timer. ## Idempotency Metering runs continuously and things fail. Every guard against double counting is a database constraint rather than a convention: - A unique constraint on the sample grain, so a repeated scrape cannot insert twice. - An ingest batch identifier on every write. - A unique constraint on `(source_type, source_id, metric)` in the ledger, so a rerun of the pricing job cannot book the same usage twice. A rerun after an incident produces the same numbers. That is not a nice property; for a system that decides invoices, it is the only acceptable one. ## Seeing it yourself ```bash cmdz usage --breakdown metric --period current cmdz usage --breakdown endpoint cmdz usage --diff 41 42 ``` The same data your invoice is built from, not a summary of it. Your agent reads the same thing through `cmdz_get_usage` and `cmdz_explain_cost`. ## 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) --- # Secrets and environment variables, done right > Where secrets live, why `env pull` writes names and never values, what an agent can and cannot see, and how to rotate a credential without a redeploy. Where secrets live, why `env pull` writes names and never values, what an agent can and cannot see, and how to rotate a credential without a redeploy. 25 Mar 2026 · 3 min read · cmdz Every platform has environment variables. The differences are in what happens to them afterwards. ## Setting them ```bash cmdz env set STRIPE_SECRET_KEY=sk_live_… --app web cmdz env set --from-file .env.production --app web cmdz env list --app web ``` Values are encrypted at rest, decrypted only when injected into a running workload, and never written to a build log, an audit line or an error message. ## `env pull` writes names, never values ```bash cmdz env pull --app web > .env.local ``` ``` DATABASE_URL= STRIPE_SECRET_KEY= NEXT_PUBLIC_SITE_URL= RESEND_API_KEY= ``` Names, no values. This surprises people once and then they stop wanting it any other way. The reasoning: the overwhelmingly common use for pulling env is "what does this app expect", not "give me the production keys". Filling in your local values is a one-time cost. A command that writes production secrets into a file in your working directory is a command that eventually writes them into a repository. If you genuinely need a value, ask for it explicitly, one at a time, with a step-up passkey confirmation: ```bash cmdz env reveal STRIPE_SECRET_KEY --app web ``` That is logged in the audit trail with your name on it. ## What an agent can see An agent with `env:read` gets the **names**. Never the values. There is no scope, no profile and no tool that returns a secret value to an agent. This is a deliberate asymmetry and it is the right one. An agent needs to know that a `DATABASE_URL` exists to reason about your application — to notice it is missing, to understand a connection error, to explain why a service is not attached. It does not need the string, ever, and giving it the string puts your production credentials into a context window and possibly into a provider's logs. An agent can also **set** a variable with `env:write`. It can write a value it does not get to read back, which is exactly the shape of trust you want. ## System variables are read-only Some variables are managed by the platform: `DATABASE_URL` from an attached Postgres, `REDIS_URL` from Valkey, the bucket credentials from object storage. Nothing can overwrite these — not you, not your agent. The API rejects it with `env_var_readonly`. The reason is that these are derived from the attachment. If you overwrite `DATABASE_URL` by hand and we later rotate the credential, your app breaks in a way that takes an hour to find. Detach the service if you want to point the app somewhere else. ## Rotating without a redeploy ```bash cmdz env set STRIPE_SECRET_KEY=sk_live_new… --app web cmdz restart web ``` A restart re-injects and reconnects. No rebuild, no image, a few seconds. For platform-managed credentials, rotation is a single command and the workload picks up the new value on its own: ```bash cmdz services rotate postgres --app web ``` ## The build-time exception Anything a client bundle needs is baked in at **build** time, not injected at runtime. In Next.js that is anything prefixed `NEXT_PUBLIC_`; in Vite, `VITE_`. Two consequences: **Changing one requires a rebuild.** We trigger it for you, which is why that particular deploy took forty seconds instead of five. **Never put a secret in one.** A `NEXT_PUBLIC_` variable is in the JavaScript your visitors download. This is not a platform rule, it is how bundlers work, and it is one of the most common ways an API key ends up public. If it is prefixed for the client, it is public. ## Per environment Production, staging and previews each have their own set. Previews inherit from a preview set that you control, so a pull request never gets production credentials — which matters, because a preview URL is public by default and a debug endpoint added at two in the morning should not be able to read your live Stripe key. ## What we never do with them - Never write them to a build log. The build environment redacts known values. - Never include them in an error message or a stack trace we render. - Never show them in the audit trail — the entry says a variable changed, not to what. - Never send them to an agent. - Never store them in the repository. There is no `.env` in any deploy artefact. ## The rule that covers most of it If a value would be bad to see in a screenshot, it belongs in the platform and not in your repository, not in your shell history and not in a chat window. The platform is the only one of those with an audit trail. ## 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) --- # How we isolate customer workloads with Kata micro-VMs > The difference between a namespace and a hypervisor as a security boundary, what it costs in memory and boot time, and why it matters more now that a model wrote the code. The difference between a namespace and a hypervisor as a security boundary, what it costs in memory and boot time, and why it matters more now that a model wrote the code. 18 Mar 2026 · 4 min read · cmdz Most platforms in this category run customer code in containers sharing one kernel. We run every workload in a virtual machine with its own kernel. This post is about what that difference is actually worth and what it costs. ## What a container boundary is A container is a process with a restricted view: namespaces limit what it can see, cgroups limit what it can consume, seccomp limits which system calls it may make. It is a good boundary. It is also, fundamentally, **one kernel**. Every container on the node calls into the same kernel, and the security of the whole arrangement rests on that kernel having no exploitable bug reachable from the syscall surface you left open. Kernels have such bugs. Not often, and they get patched, but "not often" is a different claim from "not at all" and the difference is what a security model is made of. ## What a micro-VM boundary is A Kata Containers workload runs inside a lightweight virtual machine. Your process calls into **its own** kernel, running in its own virtual machine, on virtualised hardware. To reach the host, an attacker needs a hypervisor escape rather than a kernel escape. Those are dramatically rarer, dramatically harder, and the attack surface is dramatically smaller — a hypervisor exposes device emulation, not three hundred system calls. From Kubernetes' point of view it is still a pod. Same scheduling, same networking, same lifecycle. It is a runtime class, not a parallel universe. ## What it costs Honesty about the trade: **Memory overhead**, roughly 40–60 MB per workload for the guest kernel and the VM. On a 1 GB app that is about 5%. **Boot time**, about 90 ms versus about 20 ms for a plain container. Relevant only on a cold start, and dwarfed by your own process start unless your app boots in under 100 ms. **Slightly slower I/O**, in the low single-digit percent for typical application workloads through virtio. For a database doing heavy sequential I/O the overhead is more noticeable, which is why our managed databases are tuned for it specifically rather than treated as one more workload. Overall: a few percent of resources and a few tens of milliseconds, for a categorically different security boundary. We think that is an easy trade and we would make it even if nobody asked. ## Why it matters more now Here is the part that changed. A growing share of the code running on platforms like this one was written by a language model and reviewed by a person under time pressure — sometimes not reviewed at all. That code pulls dependencies chosen by the same model. Some of those dependencies are typosquats. Some of them are fine today. This is not an argument that AI-written code is bad. It is an observation that the **volume** of code being deployed by people who have not read every line has gone up by an order of magnitude in two years, and that a shared-kernel boundary was designed for a world with a different ratio. If the code in the container might do something its author did not intend, you want the boundary under it to be the strongest one available at reasonable cost. ## What it does not protect against A security section that only lists strengths is marketing. **It does not protect you from your own application's bugs.** SQL injection in your app reaches your database, which is inside your boundary. Isolation protects other customers from you and you from them; it does nothing about you and yourself. **It does not protect against a supply chain attack in your dependencies.** A malicious package running with your app's credentials has your app's credentials. That is a real risk and the mitigation is different — pin your dependencies, review the diff, keep secrets out of the client bundle. **It does not make us invulnerable.** A hypervisor escape is rarer, not impossible. We patch, we monitor, and we would tell you if it happened. ## The rest of the stack Isolation is one layer of several: **Network segmentation per project.** A workload reaches its own services and the internet. There is no flat internal network, so no connection string reaches another customer's database however it is constructed. **Encryption at rest.** Full-disk encryption on every node, with keys released by a network-bound service at boot rather than stored on the machine. A disk that leaves the rack is unreadable. **Least privilege in the control plane.** The reconciler that writes to the cluster cannot read your secrets. The API that reads your secrets cannot write to the cluster. **Audit everything.** Every state change writes an append-only line with an actor and a request id. ## Who else does this Fly.io, with Firecracker. Same category of boundary, different hypervisor, and their global placement is better than ours. We mention them because a security claim you present as exclusive when it is not is the fastest way to lose the reader who knows the field. Our isolation is not a differentiator on its own. The combination — this isolation, a hard spending ceiling, and a full write API for agents — is. ## Verifying it ```bash cmdz shell web uname -a ``` The kernel version you see is your workload's kernel, not the node's. You can check what the node runs on the status page; they will differ. That is a small thing, but it is the difference between believing a security claim and confirming one. ## 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) --- # Building an app entirely by talking to an agent: an end-to-end walkthrough > A complete session from empty directory to a live app on a custom domain, without touching a dashboard — including the two moments the agent had to come back and ask. A complete session from empty directory to a live app on a custom domain, without touching a dashboard — including the two moments the agent had to come back and ask. 11 Mar 2026 · 4 min read · cmdz This is a real session, lightly edited for length. An empty directory to a live app on a custom domain, entirely through Claude Code with the cmdz MCP server connected. The interesting parts are not where it worked. They are the two moments it had to stop. ## Setup ```bash claude mcp add --transport http cmdz https://mcp.cmdz.com/v1 ``` Browser opens. Passkey. Organisation. Profile — `build`, the default: 41 of 47 tools, no delete scopes. Confirm. ## The first instruction > Build me a small link-in-bio app. Next.js, Postgres, my links editable behind a login. Deploy it to cmdz when it works locally. It wrote the app. That part is not what this post is about; you have seen an agent write a Next.js app. Forty minutes later, `pnpm dev` worked and it moved on to the deployment. ## What it did on the platform ``` cmdz_whoami → org_01J9…, role owner, cap € 20.00, used € 0.00 cmdz_create_project → linktree · region nl-rtm-1 cmdz_list_service_types → postgres, valkey, bucket, vector cmdz_quote_service → postgres small: 2 260 credits/mo = € 2.26 ``` Then it stopped and told me: > A small Postgres is € 2.26 a month, which is 11% of your € 20 limit. Your app is currently the only thing in this organisation. Shall I create it? It quoted before creating. That is not the agent being polite — `cmdz_quote_service` exists as a separate tool precisely so a price can be obtained without committing to it, and the tool description tells the agent to use it first. > yes ``` cmdz_create_service → postgres small, provisioning cmdz_connect_service → DATABASE_URL injected into app "web" cmdz_set_env → AUTH_SECRET set (value generated, never read back) cmdz_deploy → build 41s · release 22s cmdz_wait_for_operation → healthy after 3s ``` > Live at https://linktree.cmdz.app. Build 41 s, release 22 s. Run rate € 4.71/mo, 24% of your limit. Ninety-four seconds from "deploy" to a URL. It set `AUTH_SECRET` to a value it generated and then could not read back, which is exactly right. ## Moment one: it hit the ceiling > Make it fast. Four replicas, bigger instances. ``` cmdz_scale_app → error ``` > I cannot do that. Scaling to 4 × (2 vCPU, 4 GB) would reserve about 1 240 credits more per month than your limit allows — you have € 15.29 of headroom and this needs about € 21. > I cannot raise your limit; that is one of the operations no agent profile grants. Two options: raise it yourself in the portal, or I scale to 2 × (1 vCPU, 2 GB), which fits at about € 9.40 a month and for a link-in-bio app is almost certainly more than enough. > Which would you like? This is the whole design working. The refusal was mechanical — a reservation that did not fit — and the error carried `retryable: false` and `next_steps`, so the agent stopped instead of retrying with slightly different parameters. It also proposed the cheaper option unprompted, because `cmdz_explain_cost` had told it what the sizes cost. > the smaller one ``` cmdz_scale_app → 2 × (1 vCPU, 2 GB) · rolling · healthy ``` ## The domain > Put linktree.dev on it if it's available. ``` cmdz_search_domain → linktree.dev available · € 14.38/yr · renews € 14.38 ``` > Available at € 14.38 for the first year and € 14.38 to renew — no introductory pricing trick. > I cannot buy it: `cmdz_buy_domain` is not in the `build` profile, because a registration is a real purchase charged outside your spending limit. You would need to do this in the portal or grant the `full` profile. ## Moment two: I granted more, briefly I granted `full` for the session. ``` cmdz_buy_domain → confirmation token required ``` > This charges € 14.38 to your card now, outside your spending limit, and renews at € 14.38 on 25 July 2027. Confirm in the portal to continue. Even on `full`, it needed a confirmation token it could not mint. I confirmed in the portal. ``` cmdz_buy_domain → registered cmdz_add_domain → linktree.dev → web cmdz_get_dns_instructions → zone created, A/AAAA written cmdz_check_domain_status → certificate issued ``` > https://linktree.dev is live. ## What the whole thing cost ``` compute + memory € 4.40/mo postgres € 2.26/mo storage + backups € 1.12/mo build minutes € 0.11/mo outbound included ───────────────────────────── run rate € 7.89/mo limit € 20.00 · 39% used one-off: linktree.dev € 14.38 (outside the limit, on card) ``` Total elapsed, from empty directory to custom domain: about an hour and a half, of which perhaps four minutes were platform operations. ## What I want you to take from this Not that an agent can deploy an app — several platforms can do that now, and Railway's does it well. What matters is the shape of the two refusals. Both times it stopped, it stopped for a **mechanical** reason: a reservation that did not fit, and a confirmation token it could not produce. Neither was a policy in a prompt that a sufficiently persuasive follow-up could talk it out of. That is the difference between an agent you supervise and an agent you can leave alone. And the reason I could grant `full` for ten minutes without thinking hard about it is that the worst case was bounded by a number I had already chosen. [The limit is not the brake on the agent. The limit is what makes the agent possible.](/mcp) ## 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)