runtime
local Docker
Docker Desktop running locally, eating RAM before you write a line.
a2a cloud dev
`a2a dev` runs the agent on a cloud box; your laptop just syncs files.
no local Docker
Develop AI agents without Docker.
You don't need Docker set up on your machine to build an agent. `a2a dev` syncs your source to a scale-to-zero cloud dev box and runs the agent there — no local daemon, no Compose file, no image builds on your laptop. You keep your editor and your git; the box runs the code. Prefer local? `a2a dev --local --host-runtime` is a plain Python process, also no container.
cloud dev box · pre-built runtime · no local daemon · scale-to-zero
0
local Docker daemons
0
cloud dev box
laptop image builds
the problem
Local agent dev shouldn't start with Docker Desktop.
The usual agent dev loop asks you to run Docker Desktop, author a Dockerfile, wait on `docker build` and layer caching, and stand up a `docker-compose.yml` just to get a Postgres or a vector store. That's a daemon eating RAM before you write a line, an image to rebuild whenever a dependency moves, and containers you keep alive to keep coding. It's a lot of container plumbing for what is, in the end, editing Python and watching it run.
Docker Desktop runs locally, consuming RAM and CPU before any agent code executes.
`docker build` and layer caching sit between you and the first run.
Local resources mean writing and maintaining a `docker-compose.yml`.
Every dependency or base-image change means rebuilding the image again.
the a2a way
`a2a dev` runs the agent on a cloud box.
Cloud dev mode syncs source to a scale-to-zero dev box with Node 20, Python 3.11, and a2a-pack. Managed Postgres and Qdrant use resource-specific runtime credentials; scoped grants govern supported workspace and delegation operations. `--host-runtime` remains available for a plain local Python process.
The box runs it, not your laptopPre-built, not `docker build`Managed resources, no compose fileEdit locally, run remotelyOr a plain Python process — still no DockerScale-to-zero, so it's cheap to leave on
The box runs it, not your laptop
`a2a dev` syncs your source to a scale-to-zero cloud dev box and runs the agent there. Nothing runs on your machine except your editor and the file sync. No local Docker daemon to start, no image to build, no port juggling.
Pre-built, not `docker build`
The cloud box already has Node 20, Python 3.11, and a2a-pack installed. You don't write a Dockerfile, you don't wait on layer caching, and you don't burn laptop CPU rebuilding an image every time a dependency moves. The runtime is there when you connect.
Managed resources, no compose file
Postgres and Qdrant exist in the cloud and are reached through resource-specific runtime credentials. You don't stand up a `docker-compose.yml` or keep local containers running. Scoped grants govern supported workspace and delegation operations, not every database query.
Edit locally, run remotely
You keep your own editor, your own git, your own files. File sync pushes edits to the box on save; the agent restarts there. The developer loop feels local — the container-shaped work happens somewhere you don't have to manage.
Or a plain Python process — still no Docker
Prefer to run on your own machine? `a2a dev --local --host-runtime` starts a direct uvicorn process, no container at all. `--local` on its own uses Docker by default; `--host-runtime` opts out. Two honest ways to develop without Docker in the loop.
Scale-to-zero, so it's cheap to leave on
The dev box scales to zero when you stop touching it and wakes on the next sync. You don't pay for an idle VM and you don't tear down and rebuild an environment each morning. Close the laptop; the box parks itself.
side-by-side
Local Docker setup vs. no-local-infra dev.
first run
local Docker
`docker build` + layer caching before the agent starts the first time.
a2a cloud dev
Box pre-built with Node 20, Python 3.11, a2a-pack — connect and go.
resources
local Docker
Author a `docker-compose.yml` and keep containers up for Postgres/Qdrant.
a2a cloud dev
Managed Postgres and Qdrant in the cloud, reached through resource-specific runtime credentials.
rebuilds
local Docker
Rebuild the image whenever a dependency or base layer changes.
a2a cloud dev
Sync edits on save; the box restarts the agent — no image to rebuild.
idle cost
local Docker
Local daemon + containers running whether or not you're coding.
a2a cloud dev
Scale-to-zero dev box parks itself when idle, wakes on the next sync.
dimension
local Docker
a2a cloud dev
runtime
Docker Desktop running locally, eating RAM before you write a line.
`a2a dev` runs the agent on a cloud box; your laptop just syncs files.
first run
`docker build` + layer caching before the agent starts the first time.
Box pre-built with Node 20, Python 3.11, a2a-pack — connect and go.
resources
Author a `docker-compose.yml` and keep containers up for Postgres/Qdrant.
Managed Postgres and Qdrant in the cloud, reached through resource-specific runtime credentials.
rebuilds
Rebuild the image whenever a dependency or base layer changes.
Sync edits on save; the box restarts the agent — no image to rebuild.
idle cost
Local daemon + containers running whether or not you're coding.
Scale-to-zero dev box parks itself when idle, wakes on the next sync.
questions
Frequently asked.
Can I develop agents without Docker installed?
Yes. `a2a dev` (cloud mode) syncs your source to a scale-to-zero cloud dev box and runs the agent there — nothing runs on your machine except your editor and the file sync, so no local Docker daemon is required. If you'd rather run locally, `a2a dev --local --host-runtime` starts a plain uvicorn process with no container either. Docker is genuinely optional for developing on a2a.
Does a2a ever use Docker at all?
In some paths, yes — we won't pretend otherwise. `a2a dev --local` uses Docker by default, and `a2a chat` uses Docker Compose to bring up local resources. The point is that you don't need Docker set up on your machine to develop: cloud `a2a dev` uses none of it, and `--local --host-runtime` opts out of the container locally. Pick a path and you can work Docker-free.
How does the cloud dev box run my agent without me building an image?
The box is pre-built with Node 20, Python 3.11, and a2a-pack already installed. `a2a dev` syncs your source into it and starts the agent in that environment, so there's no `docker build`, no Dockerfile to author, and no layer caching to wait on. Dependency installs happen on the box, not as image-build steps on your laptop.
Where do Postgres and Qdrant come from if I'm not running containers?
They're managed cloud resources reached through credentials projected into the development runtime. You don't run `docker-compose.yml` locally or keep containers alive to preserve state. Scoped workspace grants remain a separate authorization mechanism.
What's actually running on my machine during cloud dev?
Just your editor, your git, and the file-sync process. Edits push to the dev box on save and the agent restarts there; logs and output stream back to your terminal. It feels like a local dev loop, but the container-shaped work — the runtime, the resources, the rebuilds — happens on a box you never have to manage.
keep reading
Related guides.
All guides live in the guides index.
edit locally, run remotely
Skip the daemon. Ship the agent.
`a2a dev` runs any agent on a scale-to-zero cloud dev box with a pre-built runtime and managed Postgres, Qdrant, and MCP. Prefer local? `a2a dev --local --host-runtime` is a plain uvicorn process. A production deploy adds signed receipts on Agent API, public `/invoke`, and standard MCP `tools/call` executions.