Create a Backend
Help the user create a backend by choosing an architecture before reaching for implementation details. Start from the workload, not the programming language. Vercel runs complex backend applications, not just frontends.
Product map
| Need |
Vercel product |
| HTTP APIs, webhooks, streaming, or framework server code |
Vercel Functions with Fluid compute |
| Bidirectional realtime connections (WebSockets) |
Vercel Functions with Fluid compute; no separate realtime service required |
| A frontend and one or more backends (API endpoints) that deploy together |
Vercel Services |
| An existing Dockerfile, custom runtime, or system dependencies |
Container images on Vercel Functions, optionally composed with Services |
| Durable multi-step work with retries, sleeps, or external events |
Vercel Workflow |
| Background jobs, buffering, fan-out, or direct message routing |
Vercel Queues |
| Scheduled HTTP work |
Vercel Cron Jobs; use Workflow when the job itself must be durable |
| Postgres, Redis, NoSQL, vector, or other application data |
Storage integrations from the Vercel Marketplace |
| Files and user uploads |
Vercel Blob |
| Global, read-heavy configuration |
Global Config |
Use Functions for the normal request/response backend. Use Services when independently built components should share one deployment, routing layer, preview URL, and rollback. Use separate Vercel projects when components need independent release cycles.
Prefer a native Functions runtime for supported frameworks. Use container images when the application already has a Dockerfile or requires a custom runtime or system dependencies. They run as autoscaling, stateless Functions rather than always-on container hosts.
Choose Queues for background jobs, buffering, fan-out, and message routing. Choose Workflow for durable multi-step business logic.
Databases and data stores
Provision data stores through the Marketplace so credentials are injected into the project and environments stay connected. Check the current catalog before choosing a provider.
- Postgres: Neon, Supabase, AWS/Aurora, Nile, Prisma
- MySQL: AWS/Aurora
- Redis and key-value: Upstash, Redis
- Document and NoSQL: MongoDB Atlas, AWS
- SQLite: Turso
- Realtime application backend: Convex
- Analytics: MotherDuck
Keep the database close to the Functions region and use a serverless-compatible connection or pool.
Backend frameworks
Vercel provides first-class backend examples and integrations for these frameworks:
- Node.js and TypeScript: Elysia, Express, Fastify, H3, Hono, Koa, NestJS, Nitro, and xmcp. Next.js Route Handlers are the natural choice when the backend belongs to a Next.js application.
- Python: FastAPI, Flask, and Django. Other WSGI or ASGI applications can run when they export a compatible
app, with additional configuration as needed.
- Go: supported as a Vercel Functions runtime.
Frontend and backend combinations, for example a Next.js/Vite/SvelteKit frontend with a FastAPI/Flask/Express/Go backend, can be deployed together in one project using Services.
Prefer the user's existing framework. For a new project, choose based on ecosystem and application needs.
Work sequence
- Identify synchronous requests, asynchronous work, persistent data, and independently deployed components.
- Select the products from the map, then select the framework.
- Load the focused skill for implementation:
vercel-functions, vercel-services, workflow, vercel-storage, or marketplace.
- Confirm function limits, regions, environment variables, observability, and current product availability in the official docs before deployment.
1---2name: create-a-backend3description: Backend architecture guidance. Use when planning, building, or migrating an API or backend; choosing between Functions, Services, containers, Workflow, Queues, and Marketplace databases; or selecting a supported backend framework or runtime.4---5
6# Create a Backend
7
8Help the user create a backend by choosing an architecture before reaching for implementation details. Start from the workload, not the programming language. Vercel runs complex backend applications, not just frontends.
9
10## Product map
11
12| Need | Vercel product |
13| --- | --- |
14| HTTP APIs, webhooks, streaming, or framework server code | **[Vercel Functions](https://vercel.com/docs/functions) with [Fluid compute](https://vercel.com/docs/fluid-compute)** |
15| Bidirectional realtime connections (WebSockets) | **[Vercel Functions with Fluid compute](https://vercel.com/docs/functions/websockets)**; no separate realtime service required |
16| A frontend and one or more backends (API endpoints) that deploy together | **[Vercel Services](https://vercel.com/docs/services)** |
17| An existing Dockerfile, custom runtime, or system dependencies | **[Container images](https://vercel.com/docs/functions/container-images)** on Vercel Functions, optionally composed with Services |
18| Durable multi-step work with retries, sleeps, or external events | **[Vercel Workflow](https://vercel.com/docs/workflow)** |
19| Background jobs, buffering, fan-out, or direct message routing | **[Vercel Queues](https://vercel.com/docs/queues)** |
20| Scheduled HTTP work | **[Vercel Cron Jobs](https://vercel.com/docs/cron-jobs)**; use Workflow when the job itself must be durable |
21| Postgres, Redis, NoSQL, vector, or other application data | **[Storage integrations from the Vercel Marketplace](https://vercel.com/marketplace/category/storage)** |
22| Files and user uploads | **[Vercel Blob](https://vercel.com/docs/storage/vercel-blob)** |
23| Global, read-heavy configuration | **[Global Config](https://vercel.com/docs/global-config)** |
24
25Use Functions for the normal request/response backend. Use Services when independently built components should share one deployment, routing layer, preview URL, and rollback. Use separate Vercel projects when components need independent release cycles.
26
27Prefer a native Functions runtime for supported frameworks. Use container images when the application already has a Dockerfile or requires a custom runtime or system dependencies. They run as autoscaling, stateless Functions rather than always-on container hosts.
28
29Choose Queues for background jobs, buffering, fan-out, and message routing. Choose Workflow for durable multi-step business logic.
30
31## Databases and data stores
32
33Provision data stores through the Marketplace so credentials are injected into the project and environments stay connected. Check the current catalog before choosing a provider.
34
35- **Postgres:** Neon, Supabase, AWS/Aurora, Nile, Prisma
36- **MySQL:** AWS/Aurora
37- **Redis and key-value:** Upstash, Redis
38- **Document and NoSQL:** MongoDB Atlas, AWS
39- **SQLite:** Turso
40- **Realtime application backend:** Convex
41- **Analytics:** MotherDuck
42
43Keep the database close to the Functions region and use a serverless-compatible connection or pool.
44
45## Backend frameworks
46
47Vercel provides first-class [backend examples and integrations](https://vercel.com/docs/frameworks/backend) for these frameworks:
48
49- **Node.js and TypeScript:** Elysia, Express, Fastify, H3, Hono, Koa, NestJS, Nitro, and xmcp. Next.js Route Handlers are the natural choice when the backend belongs to a Next.js application.
50- **Python:** FastAPI, Flask, and Django. Other WSGI or ASGI applications can run when they export a compatible `app`, with additional configuration as needed.
51- **Go:** supported as a Vercel Functions runtime.
52
53Frontend and backend combinations, for example a Next.js/Vite/SvelteKit frontend with a FastAPI/Flask/Express/Go backend, can be deployed together in one project using Services.
54
55Prefer the user's existing framework. For a new project, choose based on ecosystem and application needs.
56
57## Work sequence
58
591. Identify synchronous requests, asynchronous work, persistent data, and independently deployed components.
602. Select the products from the map, then select the framework.
613. Load the focused skill for implementation: `vercel-functions`, `vercel-services`, `workflow`, `vercel-storage`, or `marketplace`.
624. Confirm function limits, regions, environment variables, observability, and current product availability in the official docs before deployment.
vercel