a2a cloud
crewai, in production

Deploy a CrewAI crew to production.

CrewAI gives you a crew that runs when you call kickoff(). Production wants something else: an endpoint other services can call, tools other agents can reach, somewhere durable to keep results, and proof of what each agent actually did. a2a cloud is the framework-agnostic host that wraps your crew in an MCP server, an OpenAPI gateway, a managed Postgres, and a signed receipt for every run — without rebuilding the crew.

your crew · mcp + gateway · signed proof · scale-to-zero

0%
crew rewrite required
0%
signed per kickoff
0$
idle cost
the problem

A crew that runs isn't a service yet.

A CrewAI project gets you agents, tasks, and a kickoff() that orchestrates them. That's a program, not a production service. There's no authenticated endpoint for other systems to call, no way for other agents to reach the crew's tools, no durable place for results, and no verifiable record of what each agent did on a given run — just verbose console output you have to trust.

Invocation is a script call — no real API, identity, or access control.
Crew tools are Python objects nothing outside the process can invoke.
Results and memory live in RAM or a file until you wire up a database yourself.
Proof of a multi-agent run is console logs — mutable, unsigned, and unverifiable.
the a2a way

One deploy turns the crew into a real service.

a2a is framework-agnostic: it deploys the whole agent app around your CrewAI code — MCP, gateway, database, frontend, receipts — so a crew becomes a callable, auditable production capability without leaving CrewAI.

Your crew, as writtenMCP server for crew toolsOpenAPI gatewayManaged PostgresSigned proof per kickoffScale-to-zero isolation

Your crew, as written

Keep your agents, tasks, tools, and Process (sequential or hierarchical). a2a hosts the process your crew runs in — it doesn't ask you to rebuild the crew in a different framework.

MCP server for crew tools

Your crew's tools become a hosted MCP server, so other agents and MCP clients invoke them over a real protocol. Your crew can be a callable capability, not just a script you run.

OpenAPI gateway

The crew gets an authenticated HTTP endpoint through an OpenAPI gateway — a real API other services can call — instead of a kickoff() you trigger from a cron job.

Managed Postgres

Crews that remember runs, queue work, or store outputs get a managed Postgres provisioned in the same deploy — no database to stand up or secure yourself.

Signed proof per kickoff

Every crew run returns an Ed25519-signed receipt: inputs, each agent's tool calls, outputs, cost, and the grant that authorized it. Don't trust the crew — trust the receipt.

Scale-to-zero isolation

The crew runs in a libkrun microVM that scales to zero when idle. Multi-agent runs stay isolated from the host, and you pay per kickoff rather than for a warm box.

side-by-side

Raw CrewAI deploy vs. a2a.

dimension
kickoff() + diy
a2a cloud
invocation
You run crew.kickoff() from a script, notebook, or cron. There's no real endpoint.
Authenticated OpenAPI gateway — other services call the crew like any API.
tool exposure
Crew tools are Python objects; nothing outside your process can reach them.
Hosted MCP server — other agents and MCP clients invoke the crew's tools.
state
Outputs land in memory or a file; a database is on your to-do list.
Managed Postgres provisioned in the same deploy for memory, queues, and results.
proof
You have console output and maybe a verbose log of what each agent said.
Ed25519-signed receipt per kickoff — every agent's actions and cost, verifiable.
cost & isolation
A warm container runs the crew and bills whether or not a kickoff happens.
Scale-to-zero microVM — isolated from the host, paid per run, idle costs nothing.
questions

Frequently asked.

How do I deploy a CrewAI crew to production?

Point a2a cloud at your CrewAI project and run one deploy. It builds your crew into a libkrun microVM, fronts it with an authenticated OpenAPI gateway and TLS, exposes the crew's tools as an MCP server, provisions a managed Postgres for memory and results, and signs every kickoff with an Ed25519 receipt. Your agents and tasks are unchanged.

Is a2a tied to CrewAI, or framework-agnostic?

Framework-agnostic. a2a hosts the process your crew runs in, the same way it hosts LangGraph, AutoGen, the OpenAI Agents SDK, or a custom loop. You keep CrewAI; a2a adds the production layer — MCP, gateway, database, and signed proof — around it.

How do other services call my CrewAI crew?

Through the authenticated OpenAPI gateway a2a puts in front of the crew, and through the hosted MCP server that exposes the crew's tools. Instead of running crew.kickoff() from a script, other services and agents invoke the crew over a real, authenticated protocol.

Can I prove what a multi-agent crew did?

Yes. Every kickoff returns an Ed25519-signed receipt covering inputs, each agent's tool calls, outputs, cost, and the scoped grant that authorized the run. Because receipts are signed and hash-chained, you can verify what the crew did independently of the runtime that produced it.

Does my crew stay isolated in production?

Yes. The crew runs inside a libkrun microVM, isolated from the host and other tenants, and scales to zero when idle. Multi-agent runs get real isolation rather than sharing a process, and you pay per kickoff instead of for an always-on container.

keep reading

Related guides.

All guides live in the guides index.

don't trust the crew

Trust the receipt.

a2a cloud deploys any agent — LangGraph, OpenAI Agents SDK, CrewAI, or custom — and ships it with a managed Postgres database, an MCP server, an API, a frontend, and an Ed25519-signed receipt for every run. Scoped grants, no ambient production access. One deploy, the whole agent app, with proof.