FastAPI vs Next.js for AI agents in 2026
Should the AI agent live in your Next.js API routes or in a separate FastAPI backend? Here's the decision matrix from 30+ production AI agent deployments - when Next.js is enough, when FastAPI is mandatory.
Table of contents
FastAPI vs Next.js for AI agents is the wrong question - the real question is whether your AI agent has state and concurrency requirements that Next.js API routes weren’t designed for. Most production AI agent SaaS applications need both: FastAPI for the agent runtime, Next.js for the frontend and marketing site.
This post lays out the decision matrix.
When Next.js API routes are enough
Next.js with the App Router + React Server Components can host AI agent logic via API routes or Server Actions. This works fine for:
- One-shot chat completions with no tool calling
- No streaming requirements (full response on request)
- Simple RAG with one vector store, single-tenant
- Stateless agents - no conversation persistence beyond the current request
- Vercel deployment with edge functions
- Small scale - < 100 concurrent users, < 1k requests/day
If your AI feature is “summarize this text” or “generate variations of this prompt,” Next.js handles it well. ShipFast-style boilerplates take this approach.
When you need FastAPI as a separate backend
FastAPI becomes necessary when you hit any of:
1. Long-running agent workflows
LangChain agents that plan and execute multi-step tasks (10-30 seconds end-to-end) don’t fit Next.js’s serverless timeout model on Vercel (10s on Hobby, 60s on Pro, 5 minutes on Enterprise). FastAPI deployed on a long-running container has no such limit.
2. WebSocket streaming
Real-time streaming of agent responses with tool-call approvals, resumable streams, and reconnect handling is much cleaner in FastAPI’s async model with WebSocket endpoints than in Next.js’s request/response loop.
3. Background work
Document re-indexing, scheduled syncs from Google Drive / S3, billing reconciliation - these are background tasks. Celery + Redis is the canonical stack. Next.js has no native background worker model.
4. Multi-tenant RAG
Production RAG with per-tenant scoping, embedding caching, parser swapping, and per-org quota tracking is too much logic to live in Next.js API routes. A separate Python service with proper layered architecture (repository / service / route) keeps it sane.
5. Heavy LLM SDK usage
OpenAI, Anthropic, Google - every SDK has nuanced retry / streaming / function-calling semantics. Centralizing this in one Python service (with proper abstraction) is easier to maintain than scattered TypeScript calls across Next.js routes.
6. Compliance + audit log
Multi-tenant SaaS often needs structured audit logs (who did what, when, against which org). A FastAPI service with middleware that writes audit events to Postgres is a clean pattern. Same in Next.js is doable but awkward.
The hybrid pattern (what AgentBoiler ships)
In 30+ production AI agent deployments, the most stable architecture has been FastAPI for the agent backend + Next.js for the frontend and marketing site.
┌─────────────────┐ ┌─────────────────────┐│ Next.js 15 │ ◄─────► │ FastAPI 0.135+ ││ (frontend + │ REST │ (agent runtime + ││ marketing) │ WS │ billing + RAG) │└─────────────────┘ └─────────────────────┘ │ │ │ ▼ │ ┌─────────────────────────┐ │ │ PostgreSQL + Redis + │ └─────────────►│ Vector store + Celery │ └─────────────────────────┘Next.js handles:
- Marketing site (landing, pricing, blog, FAQ)
- Auth UI (login, register, password reset)
- Dashboard chrome (layout, navigation, theme)
- Static or fast-rendering pages (i18n, SEO, OG images)
FastAPI handles:
- Agent runtime (LangChain with WebSocket streaming)
- Tool calling and conversation persistence
- RAG pipeline (vector search, ingestion, re-indexing)
- Multi-tenant billing (Stripe Checkout + webhooks + credits)
- Background tasks (Celery + Redis)
- Admin operations (refunds, impersonation, audit log)
This is what AgentBoiler ships pre-wired.
When NOT to use the hybrid
- You’re building a prototype to validate demand. Use Next.js + Vercel + Supabase, get a working demo in a day, validate. Switch to hybrid when traction justifies the complexity.
- Your AI feature is one-shot, no streaming. Next.js API routes are fine.
- Your team is Python-allergic. A unified TypeScript codebase (Next.js + LangChain.js) has merit even with the constraints - pick what your team will actually maintain.
The cost of the hybrid
The hybrid pattern adds operational complexity: two services, two deployments, CORS between them, latency overhead on cross-service calls. For a solo developer this can be too much.
AgentBoiler mitigates this by shipping the entire hybrid stack as one repo with one make bootstrap command - Docker Compose orchestrates both services plus Postgres / Redis / Milvus / Celery. You get the architecture benefits without the setup tax.
Bottom line
Use Next.js alone for one-shot AI features and prototypes. Use FastAPI + Next.js hybrid when you have streaming agents, multi-tenant billing, RAG over user-owned documents, or background work - basically anything that looks like a production AI agent SaaS.