# Infrastructure for Coding Agents Zerops was built on the idea of **environment parity** — giving developers the full development lifecycle, from remote development to highly available production, with the observability and developer tools for maximum flexibility, and sensible defaults so the configs stay reasonable. Turns out that's **exactly what coding agents need** to produce and iterate on production-ready applications. ## What is it An **[MCP server](/zcp/overview)** for your agents — with an optional remote cloud development environment container to run them in — that makes use of the flexibility and processes Zerops provides. There's no "Zerops system prompt" hogging your context window. The MCP server is a thin layer that makes **your agent a Zerops platform power user** — when needed — so it understands: - how networking, scaling, debugging, build & deployment, environment variables, and service provisioning work on the platform - the development loop: start a dev server → implement → deploy to stage → verify The depth of the platform underneath is what gives the agent room to actually work. A single agent can scaffold and iterate on projects with multiple runtimes (`app`, `api`, `worker`) backed by multiple [managed services](/features/infrastructure) (object storage `storage`, Postgres `db`, Elasticsearch `search`, NATS `broker`, Valkey `cache`) — just as easily as it can work on a simple Next.js presentational website. A **[recipe ecosystem](https://app.zerops.io/recipes)** covering the most popular frameworks — pre-prepared for the whole lifecycle — gives the agent a baseline to start from, or a guide for setting up any stack on Zerops. ```text ┌─ ZCP MCP ────┐ ┌─ recipes for any stack ────────────────────────────────┐ │ │ │ │ │ Claude Code │ │ │ │ Codex │ │ Bun, Deno, Node.js, Go, Java, Python, Rust, Gleam │ │ Gemini CLI ├───►│ │ │ opencode │ │ Ruby, PHP, .NET, Laravel, Next.js, Nuxt, Astro, Svelte │ │ │ │ │ └───────┬──────┘ │ React, Vue, Angular, Solid, Qwik, Analog, Nest.js │ │ │ │ │ │ │ │ └────────────────────────────────────────────────────────┘ │ │ zcp with agent has root ssh access to runtime services, │ runs dev server on dev, deploys to stage, verifies │ ├───────────────────────────────────────────────────────────────┐ │ │ ┌─ complex project ────────────────────────────────────────┐ ┌─ simple project ───┐ │ │ │ │ │ │ │ ▼ │ │ ▼ │ │ ┌────────────┐ │ │ ┌──────────┐ │ │ │ zcp │ │ │ │ zcp │ │ │ │ Ubuntu │ │ │ │ Ubuntu │ │ │ └────────────┘ │ │ └──────────┘ │ │ │ │ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ ┌──────────┐ │ │ │ appdev │ │ apidev │ │ workerdev │ │ │ │ appdev │ │ │ │ Bun │ │ Golang │ │ Python │ │ │ │ Node.js │ │ │ └────────────┘ └────────────┘ └────────────┘ │ │ └──────────┘ │ │ │ │ │ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ ┌──────────┐ │ │ │ appstage │ │ apistage │ │workerstage │ │ │ │ appstage │ │ │ │ Bun │ │ Golang │ │ Python │ │ │ │ Node.js │ │ │ └────────────┘ └────────────┘ └────────────┘ │ │ └──────────┘ │ │ │ └────────────────────┘ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ │ │ db │ │ search │ │ broker │ │ cache │ │storage │ │ │ │Postgres│ │Elastic │ │ NATS │ │ Valkey │ │ S3 │ │ │ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘ │ └──────────────────────────────────────────────────────────┘ ``` :::tip[Platform-first, not agent-first] Most coding-agent platforms went agent-first, then bolted on infrastructure — where it runs, how it reaches the database, how its output becomes production-ready, which third-party services to wire up. **Zerops went platform-first.** The complete development lifecycle existed before coding agents did; we taught them to operate it — **not just how to call APIs, but how to ship software the way a senior developer would.** ::: ## Main features ### Your agent, your subscription Bring whichever agent you already use. Claude Code today; Codex, Gemini CLI, opencode, and any MCP-capable client next. The container is a regular Ubuntu — install your own CLI tools, drop in your `.claude` / `.cursor` configs, attach your IDE over SSH. **Zerops doesn't resell tokens or proxy your model calls** — sign in with your own Anthropic / OpenAI / Google subscription and the agent talks to its provider directly. ### An ordinary Zerops project underneath The agent operates inside a normal Zerops project — same shape as production. Managed databases (PostgreSQL, MariaDB, ClickHouse), key-value stores (KeyDB, Valkey), search (Elasticsearch, Meilisearch, Typesense), vector store (Qdrant), message queues (NATS, Kafka), object and shared storage, managed Nginx — all on a private network, addressable by hostname. The same pipeline that deploys here can deploy to a separate HA production project with no `zcp` service attached. Not a sandbox the work outgrows. ### Human ↔ agent handover The agent and the human share the same workspace — same filesystem, same SSH key, same Cloud IDE in the browser, same remote-dev attach from your local IDE. Take over mid-session, set something up before the agent runs, debug in the same container the agent just left. Nothing reaches production until you merge the PR — the agent opens it, you gate it. ### Recipes for any stack Runtimes for Bun, Deno, Node.js, Go, Python, Rust, Java, .NET, PHP, Elixir, Gleam — with curated recipes for the framework on top: Next.js, Nuxt, Astro, Svelte, React, Vue, Angular, Solid, Qwik, Analog, NestJS, Laravel, and more. Pick a recipe, select the **AI Agent** environment, and the project comes up with a working dev runtime, a stage runtime, the right managed services wired in, and a coding agent briefed on the Zerops surface. ## How it works in practice The agent reaches your project's private network one of two ways: - **Remote** — a `zcp` service deployed into the project runs the agent. You attach to it with Claude Code's IDE extension, with any IDE that supports remote development (Cursor, Windsurf, VS Code Remote), or by running [`zcli vpn up`](/references/networking/vpn) and ssh-ing into `zcp` to drive the rest of the project from a shell. - **Local** — install the `zcp` MCP on your machine and run `zcli vpn up` to join the network. From there your IDE, agent, and shell can ssh directly into any container. Either way, the agent reaches [managed services by hostname](/references/networking/internal-access) (`db:5432`, `cache:6379`), deploys through the [Zerops pipeline](/features/pipeline), and reads logs and events the same way you would. **Remote (zcp service)** ```text https://my-app.com │ ▼ ┌────────────────────────────────────────────────────────────┐ │ Zerops development project (private network) │ │ ┌─────────────────┐ ┌──────────┐ ┌──────────┐ │ │ │ project ctrl │ │ stats │ │ logger │ │ │ │ + L3 balancer │ │ │ │ │ │ │ │ + firewall │ │ │ │ │ │ │ └────────┬────────┘ └──────────┘ └──────────┘ │ │ │ │ │ ┌────────┴────────┐ │ │ │ L7 balancer │ │ │ │ (Nginx) │ control plane │ │ └────────┬────────┘ ssh into other services │ │ │ dev runtime fs mounted │ │ ├─────────────────┬─────────────────┐ │ │ ┌──────┴──────┐ ┌───────┴───────┐ ┌──────┴──────┐ │ │ │ appdev:3000 │ │ appstage:3000 │ │ zcp service │ │ │ │ dev runtime │ │ stage runtime │ │ agent + MCP │ │ │ └──────┬──────┘ └───────┬───────┘ └──────┬──────┘ │ │ │ │ │ │ │ └─────────────────┼─────────────────┘ │ │ │ │ │ ┌──────────────┴────────────┐ │ │ │ │ │ │ ┌──────┴──────┐ ┌──────┴──────┐ │ │ │ db:5432 │ │ cache:6379 │ │ │ │ Postgres │ │ Valkey │ │ │ └─────────────┘ └─────────────┘ │ │ │ └────────────────────────────────────────────────────────────┘ ``` **Local (zcli vpn up)** ```text https://my-app.com │ ▼ ┌────────────────────────────────────────────────────────────┐ │ Zerops development project (private network) │ │ ┌─────────────────┐ ┌──────────┐ ┌──────────┐ │ │ │ project ctrl │ │ stats │ │ logger │ │ │ │ + L3 balancer │ │ │ │ │ │ │ │ + firewall │ │ │ │ │ │ │ └────────┬────────┘ └──────────┘ └──────────┘ │ │ │ │ │ ┌────────┴────────┐ │ │ │ L7 balancer │ │ │ │ (Nginx) │ │ │ └────────┬────────┘ │ │ │ │ │ ├─────────────────┐ │ │ ┌──────┴──────┐ ┌───────┴───────┐ │ │ │ appdev:3000 │ │ appstage:3000 │ │ │ │ dev runtime │ │ stage runtime │ │ │ └──────┬──────┘ └───────┬───────┘ │ │ │ │ │ │ └────────┬────────┘ │ │ │ │ │ ┌─────┴─────────────────────┐ │ │ │ │ │ │ ┌──────┴──────┐ ┌──────┴──────┐ │ │ │ db:5432 │ │ cache:6379 │ │ │ │ Postgres │ │ Valkey │ │ │ └─────────────┘ └─────────────┘ │ │ │ └──────────────────────────────▲─────────────────────────────┘ │ │ VPN tunnel │ ┌────────────────┴────────────────┐ │ IDE / terminal │ │ + agent │ │ + zcp MCP │ │ │ │ $ curl zerops.io/zcp/install.sh │ │ $ zcp init │ │ $ zcli vpn up │ └─────────────────────────────────┘ ``` The agent runs through two workflows. **Bootstrap** settles which services and runtime targets the app needs. **Develop** is the short work loop — edit code on `appdev`, deploy to `appstage`, check it's reachable, verify behavior against `db:5432` and `cache:6379`, fix from evidence. A session ends with a URL you can open, or a specific blocker — failure category, attempts, what's still needed. Same hostnames, same managed services, same pipeline as production — just at smaller scale. See [Workflows in depth](/zcp/reference/agent-workflow) for both. ```text zcp (local or remote) │ ▼ edit code on appdev ◀────────────────────────┐ └ dev server, hot reload │ │ │ ▼ │ deploy to appstage │ │ │ ▼ │ check reachability │ │ │ ▼ │ verify behavior ─── fail ─────┐ │ │ │ │ │ pass ▼ │ ▼ read logs / events │ URL (proof) fix from evidence ─────┘ ``` Once the loop produces verified work, the agent doesn't push to production. It hands off — through whichever path your team uses: a tag push, a protected-branch merge, a manual `zcli` release, a pull request, or a CI job. **A human gates the release**, and the production deploy runs into a [separate production project](/zcp/security/production-policy) that has no `zcp` service at all. ```text Dev project GitHub Prod project ┌─────────────────────┐ ┌──────────────┐ ┌─────────────────────┐ │ appdev │ │ │ │ app (HA) │ │ appstage │ │ Pull │ │ │ │ │ push │ Request │ CI/CD │ db (HA) │ │ db, cache │ ────▶ │ │ ────▶ │ │ │ │ │ + human │ │ cache (HA) │ │ zcp service │ │ review │ │ │ │ │ │ │ │ (no zcp service) │ └─────────────────────┘ └──────────────┘ └─────────────────────┘ ``` ## Where does this fit in the agent landscape With the model clear, here's where ZCP sits among adjacent tools. People say "agent infrastructure," "infra for Claude agents," "agent hosting," or "agent sandboxes" to mean different things — usually one of the categories below. #### PaaS MCPs _AWS MCP servers · Railway MCP · Fly.io MCP · Render MCP_ Most major PaaS providers have shipped an MCP — provision services, deploy code, list resources, read operational state. Great for "let my agent ship to my Railway account." These are *deploy and operate* surfaces, driven from outside the platform — and they reflect what's underneath: platforms optimized for day-one deploy that tuck the infrastructure behind a wall. Once an agent needs to actually *develop* against that infrastructure — debug a failed health check, follow real logs, hit Postgres from inside the network, inspect what a build is doing, run the dev loop before it ships anything — the wall stops it. That's by design on those platforms, not a missing feature. #### Cloud VPS MCPs _Hetzner Cloud MCP · DigitalOcean MCP · Linode MCP · raw SSH/server MCPs_ "Let your agent manage your Hetzner VPS." An MCP gives the agent access to a Linux box — provision it, SSH in, install Docker and Postgres and nginx, set up systemd units, point a domain at it. Maximum control, lowest cost, full Linux to play with. The same reason senior developers reach for managed platforms applies here: even if you *can* harden SSH, write nginx configs, tune `pg_hba.conf`, rotate TLS, set firewall rules, run fail2ban, and stay on top of CVEs across kernel, OpenSSL, Docker, Postgres, and nginx — you usually don't want to. Each layer is its own domain with its own gotchas, each is a security surface that drifts the moment you stop tending it, and every project becomes a snowflake. Hand that work to an agent and you also hand it the blast radius: misconfigured firewall, debug endpoint left open, port 5432 exposed to the internet, keys never rotated. ZCP is the inverse trade-off — the **guardrails** of a managed platform. Private networking, TLS, isolated services, safe defaults, managed backups, no exposed ports unless you opt in — all built in. The agent operates through [project-scoped MCP tools](/zcp/reference/mcp-operations) instead of `sudo` on a fresh Ubuntu box, so the mistakes that matter on a VPS aren't reachable from where it sits. #### Cloud dev environments with AI _GitHub Codespaces + Copilot Workspace · Gitpod · Coder_ A managed Linux container in the cloud with your editor and an AI assistant attached. Solves "where the agent runs" so state survives between sessions and machine setup stops being a question. The `zcp` service is the closest thing in this category — managed Linux container, Cloud IDE, your agent of choice — except it lives *inside* a Zerops project, addressing the project's runtimes, database, and cache by hostname, with deploys and logs as primitives the agent can call. #### Bundled agent platforms _Replit Agent · Lovable · Bolt.new · v0 · Devin · OpenHands_ The agent, the workspace, the stack, and (often) the hosting target are fused into one closed product. Fast for prototypes. Decisions are made for you. Switching agents usually means switching platforms, and production-grade primitives — a real dev/stage/prod release flow, private networking, observability — tend to be limited or absent. **ZCP doesn't bundle**: the agent and model stay yours on your own subscription, and the platform underneath is normal Zerops with the full stack of managed services, networking, deploys, and observability. #### Local coding agents _Cursor · Windsurf · Zed · Claude Code · Codex CLI · Aider · Cline_ The agent runs on your machine, edits your local checkout, runs local commands. Excellent at code changes. Anything beyond your machine — databases, networking, deploy targets, runtime logs — is yours to wire in. Install the ZCP MCP locally and run `zcli vpn up`, and any of these agents can now reach a real Zerops project alongside your local code: services addressed by hostname, deploys, logs, events. #### Code-execution sandboxes _E2B · Modal · Daytona · CodeSandbox SDK_ Ephemeral Linux environments that AI *applications* spin up — often per request — to execute generated code safely. The right primitive when you're building a product that needs a model to run untrusted code and hand back the output. They're a building block for AI applications, not somewhere a coding agent settles in to iterate on your project. Different shape from ZCP; they show up here because the names cluster nearby. #### Agent SDKs and frameworks _Cloudflare Agents · Vercel AI SDK · Mastra · Anthropic Agent SDK_ Libraries for building and shipping agents to *your* users — tool calling, memory, orchestration, model providers, sometimes hosting. They're how somebody would build a product like ZCP, not where a coding agent runs against a project. Same disambiguation — adjacent on the shelf, different shape. ## Where to start - [Quickstart](/zcp/quickstart) — AI Agent recipe, Claude Code, and a real product change in about five minutes. - [ZCP MCP overview](/zcp/overview) — What the `zcp` MCP gives the agent, where it runs, and how a run ends in proof or a blocker. - [Remote or local setup](/zcp/setup/choose-workspace) — Choose where the `zcp` MCP runs — inside Zerops with bundled tools, or beside your local editor. - [Build and ship](/zcp/workflows/build-with-zcp) — Runtime layout, development, delivery, packaging, and production release.