a2a cloud
the whole dev environment

An AI agent development environment, not a scratch stack.

Building an agent shouldn't mean assembling a laptop stack that only vaguely resembles where the agent will run. a2a cloud is an agent-native development environment: a scale-to-zero cloud dev box per agent, hot reload to a public preview URL, a real dev console, your own IDE over SSH, and managed database and vector resources declared once and provisioned in both dev and prod. Edit here, run where it'll actually ship.

cloud dev box · local mode · /_dev console · dev↔prod parity

0s
s hot-reload per save
0
dev box per agent
0
declaration, dev + prod
the problem

A generic dev setup isn't where your agent runs.

Most agent projects start life on a laptop: a Python venv, a Postgres container, a vector DB you installed by hand, and a pile of env files approximating production. It works until it doesn't — the runtime differs, the resources drift from prod, and the only way to see the agent behave is curl and print statements. Then you deploy, and the environment you developed against turns out to have been a fiction. The gap between 'runs on my machine' and 'runs in prod' is where agent bugs hide.

A hand-assembled stack drifts from the runtime and resources your agent ships against.
Local Postgres and vector stores you install by hand rarely match managed prod versions.
curl and print statements are a thin substitute for driving the agent's real surfaces.
"Works on my machine" is a promise your machine can't keep for a deployed agent.
the a2a way

One environment, from first edit to preview URL.

a2a gives each agent a cloud dev box that hot-reloads your project and serves a public preview, a local mode for the same workflow offline, a /_dev console to drive tools and inputs, and managed resources declared once for dev and prod. The pieces below overview the environment — the deeper pages go one level down.

A cloud dev box per agentLocal mode when you want itA dev console, not print statementsManaged resources with dev↔prod parityYour IDE, over SSHHot reload to a preview URL

A cloud dev box per agent

`a2a dev` rsyncs your project to the agent's scale-to-zero dev box in the cloud, hot-reloads it there on every save, and serves a public URL at https://<agent>-devbox.a2acloud.io. You develop against a real box that spins down when idle — not a laptop pretending to be production. The deeper walkthrough lives at /cloud-dev.

Local mode when you want it

`a2a dev --local` runs the same agent on your machine — Docker by default, or `--host-runtime` for direct Python — and it's offline-capable. Same command, same project, whether you're editing against the cloud box or working on a plane. One dev workflow, two places to run it.

A dev console, not print statements

The `/_dev` console lets you invoke tools, set env vars, upload test files, and stream results live. The agent card is served at /.well-known/agent-card and the workspace is mounted at .a2a/workspace/{inputs,outputs}. You drive the agent through its real surfaces instead of scattering logging through the code.

Managed resources with dev↔prod parity

Declare resources in a2a.yaml — resources.databases becomes Neon Postgres in prod, resources.memory.tiers:[vector] becomes managed Qdrant. `a2a chat` provisions the same declarations locally via Docker Compose (postgres:16-alpine with pgvector, qdrant/qdrant). One declaration, dev and prod, so the database your agent talks to in dev matches the one it ships against.

Your IDE, over SSH

`a2a ssh <agent>` drops you into a throwaway dev box — Node 20, Python 3.11, a2a-pack already logged in, git with the repo pre-cloned — over SSH-over-WebSocket through the normal HTTPS ingress, no bastion or open port. It works with VS Code Remote-SSH, Cursor, and JetBrains Gateway. The shell-level detail is at /dev-boxes.

Hot reload to a preview URL

Save a file and the cloud box reloads in about two seconds, serving the change at the agent's public devbox URL. You share a link, not a screenshot — the same URL shape your teammates and test harnesses can hit. The feedback loop is the environment's whole point.

side-by-side

Generic dev setup vs. an agent-native environment.

dimension
scratch stack
a2a environment
what it runs
A laptop stack you assembled — Python, a database container, some env files — approximating production.
A dev box running the same runtime, base image family, and prod-like managed resources as deployed agents.
resources
Local Postgres and vector DB you install and version by hand, drifting from prod.
resources declared once in a2a.yaml — Neon Postgres + managed Qdrant in prod, Docker Compose locally, same declaration.
dev surface
curl, print statements, and a REPL to poke at the agent.
A /_dev console to invoke tools, set env, upload files, and stream results — plus the agent card and workspace.
IDE
Edit locally against a stack that isn't where the agent will actually run.
a2a ssh into a dev box with your VS Code / Cursor / JetBrains Gateway session attached, repo pre-cloned.
parity
"Works on my machine" — because your machine isn't production.
The dev box is prod-like, so "works on my machine" bugs surface before deploy, not after.
questions

Frequently asked.

What is the a2a AI agent development environment?

It's the full dev experience for building agents on a2a cloud: `a2a dev` gives each agent a scale-to-zero cloud dev box that hot-reloads your project and serves a public preview URL, with a /_dev console to invoke tools and stream results. `a2a ssh` attaches your IDE to a throwaway box, and resources declared in a2a.yaml provision the same managed Postgres and vector store in dev and prod. It's an agent-native environment rather than a generic Python setup you wire together yourself.

Do I develop in the cloud or locally?

Both, from the same command. `a2a dev` rsyncs your project to the agent's cloud dev box, hot-reloads it there in about two seconds per save, and serves it at https://<agent>-devbox.a2acloud.io. `a2a dev --local` runs the same agent on your machine — Docker by default, or `--host-runtime` for direct Python — and works offline. You pick where it runs; the workflow doesn't change. The cloud-side detail lives on the /cloud-dev page.

Can I use my own IDE — VS Code, Cursor, JetBrains?

Yes. `a2a ssh <agent>` opens a throwaway, per-agent dev box over SSH-over-WebSocket through the normal HTTPS ingress — no bastion and no open port — using ephemeral Ed25519 keys and a transport grant. The box comes with Node 20, Python 3.11, a2a-pack already logged in, and git with the repo pre-cloned, and it works with VS Code Remote-SSH, Cursor, and JetBrains Gateway. The /dev-boxes page covers the shell workflow in depth.

How do databases and vector stores work in development?

You declare them once in a2a.yaml — resources.databases maps to Neon Postgres in production, and resources.memory.tiers:[vector] maps to managed Qdrant. `a2a chat` provisions those same declarations locally via Docker Compose (postgres:16-alpine with pgvector, qdrant/qdrant), so the resources your agent talks to in dev match the ones it ships against. One declaration drives both sides.

Why not just develop agents on my laptop?

You can — local mode is there for exactly that. But the a2a dev box runs the same runtime, base image family, and prod-like managed resources as your deployed agent, so "works on my machine" bugs surface before deploy instead of after. Deployed agents also get signed receipts, scoped grants, and an MCP server, and developing against a prod-like environment means you're testing against those realities the whole time, not discovering them at ship. The honest version: don't trust that it'll work in prod — develop where it already does.

don't trust the laptop

Develop where your agent actually runs.

a2a cloud is the whole agent development environment: `a2a dev` for a scale-to-zero cloud dev box with hot reload and a public preview URL, `--local` for the same workflow offline, `a2a ssh` to attach VS Code, Cursor, or JetBrains Gateway, and resources declared once in a2a.yaml — managed Postgres and Qdrant in prod, Docker Compose locally, dev↔prod parity throughout. Deployed agents ship with signed receipts, scoped grants, and an MCP server. Start with the quickstart, then go deeper on /cloud-dev and /dev-boxes.