Deploy a CrewAI Agent in 60 Seconds (With Postgres, MCP, and Signed Receipts)

Deploy a CrewAI Agent in 60 Seconds (With Postgres, MCP, and Signed Receipts)

The CrewAI part is the easy part. You define a few Agents, give them Tasks, assemble a Crew, and kickoff() runs it on your laptop in minutes. Then production asks five questions the crew can't answer on its own:

• Where does state and memory persist between runs?
• How do the agents reach tools without you hand-rolling an integration layer?
• How does anything else call the crew — an API, a frontend, another agent?
• When it does something costly or irreversible, where's the proof of what ran?

On most stacks each of those is a separate ticket. On a2a cloud they're provisioned *with* the agent the first time you deploy it. This post walks the whole path: crew → live URL with a managed Postgres database, an MCP server, an HTTP/OpenAPI surface, and an Ed25519-signed receipt for every run.

The crew you already have

Nothing about your CrewAI code changes. A minimal crew:

from crewai import Agent, Task, Crew

researcher = Agent(
    role="Researcher",
    goal="Answer the question with a concise, sourced summary",
    backstory="A careful analyst who cites what it finds.",
)

def build_crew(question: str) -> Crew:
    task = Task(
        description=f"Research and answer: {question}",
        expected_output="A short, well-supported answer.",
        agent=researcher,
    )
    return Crew(agents=[researcher], tasks=[task])

That's the artifact. The job now is to give it somewhere to live, something to remember, tools to call, and a way to be invoked.

Wrap it in an a2a skill

a2a runs your agent as a class with one or more @skill methods. Drop the crew inside one:

from a2a_pack.agent import A2AAgent, skill
from a2a_pack.context import RunContext, NoAuth

class Researcher(A2AAgent[dict, NoAuth]):
    name = "researcher"
    description = "A CrewAI research agent"

    @skill(description="Answer a research question")
    async def ask(self, ctx: RunContext[NoAuth], question: str) -> dict:
        crew = build_crew(question)
        result = await crew.kickoff_async()
        return {"answer": str(result)}

The ctx is your window into the platform — ctx.llm for model access (routed through LiteLLM, so your crew's LLM calls work without you shipping keys), ctx.sandbox for code execution, ctx.workspace for grant-scoped storage. Your crew keeps running exactly as written.

The 60-second part

Three commands:

a2a init researcher
cd researcher   # paste your crew + skill into agent.py
a2a deploy

a2a deploy tarballs the source, commits it to a managed repo, builds the image, syncs the deployment, and polls until the agent is actually serving before it hands you a public URL. You get the URL when the agent works — not when the upload finished.

What gets provisioned with it

This is the part other stacks make you assemble yourself.

A managed Postgres database

Every agent gets its own Postgres instance, isolated to that agent. It's where crew memory, conversation history, and any data your tasks write actually lives — durable between runs and across scale events. You don't create it, connect a Neon project, or paste a connection string into a secret; it's there on first deploy, scoped so the agent reaches its data and nothing reaches across to another agent's. (More on why per-agent isolation matters: [How to Give AI Agents Database Access Without Handing Over Production](/blog/give-ai-agents-database-access-without-handing-over-production).)

An MCP server

The agent's skills are exposed as MCP tools automatically. That means other agents — or any MCP client — can call your crew as a tool with zero extra config. No tool-server to write, host, or keep in sync with your code.

An API and frontend

The deploy emits a FastAPI server speaking the full A2A protocol, an OpenAPI surface, an agent card at /.well-known/agent-card, and SSE streaming for progress and human-in-the-loop. Your crew is callable over HTTP the moment it's live.

A signed receipt for every run

This is the one you can't get by gluing services together. Every run emits an Ed25519-signed receipt — a tamper-evident record of what the agent did, when, and with what inputs and outputs. Not a trace log you have to trust; a cryptographic artifact anyone can verify. When a reviewer, an auditor, or a customer asks "prove this crew only did what it was supposed to," you have the receipt instead of a screenshot of your logs. (Why that beats trace logs: [Signed Receipts vs Trace Logs](/blog/signed-receipts-vs-trace-logs-agent-audit-trail).)

Why this is the right default

The usual CrewAI-to-production story is: crew in an afternoon, then two weeks wiring a database, a tool layer, an API gateway, auth, and observability before anyone external can touch it. The infra work dwarfs the agent work.

Provisioning the database, MCP server, API, and receipts *with* the agent collapses that. You spend your time on the crew — the part that's actually your product — and the path to a callable, persistent, provable agent is the same three commands whether it's a hello-world or a production multi-agent crew.

The same path works from a LangGraph graph or a bare Python class — see [Deploy a LangGraph Agent in 60 Seconds](/blog/deploy-langgraph-agent-60-seconds). This post just starts from a CrewAI crew.

Try it

Bring a crew you already have:

a2a init my-crewai-agent
cd my-crewai-agent
a2a deploy

Crew in, live URL out — with the database, tools, API, and signed proof already attached.