Deploy
Get it running somewhere real, safely.
In short: agentFast runs in your own infrastructure — it isn't a hosted service, and your data never leaves your boundary. You need somewhere to run a Python service, a Postgres database, and optionally Redis. This page covers the shortest path and the things that will bite you.
Before you deploy anything
Four settings separate "works on my laptop" from "safe to expose." None of them are on by default, because the defaults are tuned for the five-minute quickstart.
Without a token, every endpoint is open to anyone who can reach it — including the approval endpoints, which means anyone can approve your agent's refunds.
export AGENTFAST_API_TOKEN=$(openssl rand -hex 32)
The server logs a loud warning at startup when this is unset, so it can't happen quietly.
The default allows the local playground and dashboard ports only.
cors_origins:
- https://agents.yourcompany.com
Never --in-memory in production — a restart loses every run, which is the exact failure
agentFast exists to prevent.
export AGENTFAST_DATABASE_URL=postgresql+asyncpg://user:pass@host:5432/agentfast
alembic upgrade head
Rate limits are per-process without it, so three instances means three times your intended limit.
redis_url: ${AGENTFAST_REDIS_URL}
The shortest path: Railway
Managed Postgres, managed Redis, and the API in one project. Migrations run automatically on boot.
railway init
railway add --plugin postgresql
railway add --plugin redis
railway up
Run it from your scaffolded project directory — the one holding agentfast.yaml, kb/ and
evals/. See deploy/railway/README.md
for the full walkthrough.
Other targets
Configuration for each ships in deploy/:
| Target | What it's good for | Config |
|---|---|---|
| Railway | Fastest path. Managed database and Redis in the same project | deploy/railway/ |
| Fly.io | Running close to your users, or in a specific region | deploy/fly/fly.toml |
| Google Cloud Run | You're already on GCP; scales to zero between runs | deploy/gcp/service.yaml |
| AWS App Runner | You're already on AWS | deploy/aws/ |
| Your own Docker host | Full control, or an air-gapped environment | deploy/docker-compose.yml |
It's a stateful Python service holding database connections and long-lived SSE streams. Vercel's
serverless functions are the wrong shape for it. The two Next.js apps — the playground and the
dashboard — are a fine fit, and deploy/vercel/ covers those.
The UIs
The playground and dashboard are standalone Next.js apps. Deploy them anywhere that runs Next, and point them at your API:
cd apps/dashboard
vercel
vercel env add NEXT_PUBLIC_AGENTFAST_API # https://your-api.example.com
vercel --prod
Then add those origins to cors_origins on the API, or the browser will block every request.
Scaling past one instance
Two things change, and one has a caveat worth knowing:
- Set
redis_urlso rate limits are shared rather than per-process. - Live stream re-attach is per-worker. A browser reconnecting to a run
may land on a worker that isn't running it. The replay still comes from Postgres and the client
falls back to polling
GET /api/runs/{id}, which works across workers — so this degrades rather than breaks. A Redis-backed event bus is the fix and needs no change to callers.
Runs themselves are safe across instances: approvals are claimed with a database compare-and-set, so two workers can't execute the same approved call twice.
Going-live checklist
AGENTFAST_API_TOKENsetcors_originsnarrowed to your real origins- Real Postgres,
alembic upgrade headrun redis_urlset if more than one instancetool_overridesreviewed — is everything that spends money marked high-risk?- Budgets sized for your workload
agentfast evalpassing in CI- Someone is actually watching the approval queue
The approval queue only works if a human looks at it. Before launch, decide who gets notified when a run pauses, and how. An agent waiting three days for a sign-off nobody knew about looks exactly like an agent that's broken.