/create-a-backend

name: create-a-backend
description: Backend architecture guidance. Use when planning, building, or migrating an API or backend; choosing between Functions, Services, containers, Daemons, Workflow, Queues, and Marketplace databases; or selecting a supported backend framework or runtime.
summary: Match backend workloads to the right architecture
metadata:
  priority: 7
  docs:
    - "https://vercel.com/docs/frameworks/backend"
    - "https://vercel.com/docs/functions"
    - "https://vercel.com/docs/services"
    - "https://vercel.com/docs/queues"
    - "https://vercel.com/docs/daemons"
    - "https://vercel.com/docs/workflows"
    - "https://vercel.com/docs/storage"
  sitemap: "https://vercel.com/sitemap.xml"
  pathPatterns:
    - 'Dockerfile.vercel'
    - 'Containerfile.vercel'
  promptSignals:
    phrases:
      - "backend on vercel"
      - "vercel backend"
      - "build a backend"
      - "create a backend"
      - "deploy my backend"
      - "backend architecture"
    allOf:
      - [backend, vercel]
      - [backend, docker]
      - [backend, node]
      - [backend, python]
      - [backend, queue]
    anyOf:
      - "api"
      - "database"
      - "service"
      - "workflow"
    noneOf: []
    minScore: 6
retrieval:
  aliases:
    - Vercel backend
    - backend architecture
    - backend framework
  intents:
    - build a backend
    - choose backend products
    - deploy an existing API or server
    - select a Node.js or Python backend framework
  entities:
    - Vercel Functions
    - Vercel Services
    - Vercel Queues
    - Vercel Daemons
    - Vercel Workflow
    - Vercel Marketplace
    - container images

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](https://vercel.com/docs/functions) with [Fluid compute](https://vercel.com/docs/fluid-compute)** | | Bidirectional realtime connections (WebSockets) | **[Vercel Functions with Fluid compute](https://vercel.com/docs/functions/websockets)**; no separate realtime service required | | A frontend and one or more backends (API endpoints) that deploy together | **[Vercel Services](https://vercel.com/docs/services)** | | An existing Dockerfile, custom runtime, or system dependencies | **[Container images](https://vercel.com/docs/functions/runtimes/container)** on Vercel Functions, optionally composed with Services | | Execute generated or user-submitted code, or give each user an isolated Linux workspace | **[Vercel Sandbox](https://vercel.com/docs/sandbox)**; load ⤳ skill:vercel-sandbox | | Durable multi-step work with retries, sleeps, or external events | **[Vercel Workflows](https://vercel.com/docs/workflows)** | | Background jobs, buffering, fan-out, or direct message routing | **[Vercel Queues](https://vercel.com/docs/queues)** | | Always-on workers: queue consumers, Celery/Sidekiq/BullMQ workers, job runners | **[Vercel Daemons](https://vercel.com/docs/daemons)** (beta, production only) | | Recurring or one-time scheduled work | **[Vercel Schedules](https://vercel.com/docs/schedules)** (beta; replaces legacy Cron Jobs); load ⤳ skill:vercel-schedules; use Workflow when the job itself must be durable | | Postgres, Redis, NoSQL, vector, or other application data | **[Storage integrations from the Vercel Marketplace](https://vercel.com/marketplace/category/storage)** | | Files and user uploads | **[Vercel Blob](https://vercel.com/docs/vercel-blob)** | | Global, read-heavy configuration | **[Global Config](https://vercel.com/docs/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. Choose Daemons only when a process must stay running to pull work, such as a poll-mode queue consumer or an existing Celery, Sidekiq, or BullMQ worker; daemons cannot receive traffic.

Use Sandbox when the backend needs to execute code in an isolated Linux environment or manage a user's workspace. Keep the application's HTTP endpoints in Functions or Services, and load ⤳ skill:vercel-sandbox for authentication, command execution, and workspace lifecycle. For offloading the project's own heavy builds or tests, load ⤳ skill:offload-to-sandbox.

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 Postgres
• **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](https://vercel.com/docs/frameworks/backend) 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 appli