Step-by-Step Study Material

Step 1: The Big Picture — What Problem Is Being Solved?

Traditionally, developers needed separate platforms for:

Frontend  →  Vercel (easy)
Backend   →  AWS / GCP / Azure (complex)

Vercel now lets you run both in one place.

Key Insight: Less infrastructure management = faster shipping

---

Step 2: Capability #1 — Python Backend (Generally Available)

What it is:

Run Python web frameworks directly on Vercel without managing servers.

Supported Frameworks:

What Vercel handles automatically:

• ✅ Framework detection
• ✅ Dependency installation (PyPI)
• ✅ Scaling
• ✅ Local dev + preview deployments

Available Python SDKs:

Vercel Blob      → File storage
Vercel Queues    → Background jobs
Vercel Workflows → Multi-step processes
Vercel Sandbox   → Run untrusted code safely
AI SDK           → Stream AI model responses

Real-World Example:

Delphi (10 engineers, no dedicated DevOps) ships 100+ times/day after moving from AWS ECS to Vercel

---

Step 3: Capability #2 — Container Support

What it is:

Deploy applications packaged as Docker containers — any language, any OS library.

Why containers matter:

Problem: Some apps need special system tools (e.g., ffmpeg for video)
Solution: Package everything into one container image

How it works:

Your Code + Dependencies + OS Libraries
           ↓
        Dockerfile
           ↓
    Vercel builds image
           ↓
  Stored in Vercel Container Registry
           ↓
  Deployed as Vercel Function

Example Dockerfile (Python + ffmpeg):

FROM python:3.12-slim

# Install system library (ffmpeg)
RUN apt-get update \
    && apt-get install -y --no-install-recommends ffmpeg \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY processor.py .
CMD ["python", "processor.py"]

Key Pricing Benefit:

Traditional:  Pay even when idle ❌
Vercel:       Active CPU pricing — only pay when working ✅

---

Step 4: Capability #3 — Vercel Daemons (Public Beta)

What it is:

Containers that run continuously as background workers — they don't stop between jobs.

Key Difference from Regular Functions:

Regular Function:  Request → Run → Stop
Daemon:            Start → Run → Pull work → Run → Pull work → (never stops)

Best Use Cases (Pull-Based Workloads):

• Consuming messages from a queue
• Fetching pending jobs from a database
• Continuous background processing

Configuration Example (vercel.toml):

# Frontend service
[services.frontend]
framework = "nextjs"
root = "."

# Route all traffic to frontend
[[routes]]
src = "/(.*)"
destination.service = "frontend"

# Daemon background worker
[daemons.videos]
root = "."
entrypoint = "Dockerfile"
instances.iad1 = 1    # Keep 1 instance running in Washington D.C.

Full Architecture (Video App Example):

User uploads video
      ↓
Frontend (Next.js) → sends job to Vercel Queues
      ↓
Daemon (always running) pulls job from Queue
      ↓
Processes video with ffmpeg (thumbnail + playback copy)
      ↓
Stores result in Vercel Blob

---

Step 5: Choosing the Right Tool

---

Step 6: Quick Knowledge Check

Q1: What does Vercel handle automatically for Python backends?

Detection, builds, scaling, and deployments

Q2: Why use containers instead of plain Python functions?

When you need system-level libraries (like ffmpeg) not available in standard runtimes

Q3: What makes Daemons different from regular serverless functions?

Daemons run continuously and pull work; functions start and stop per request

Q4: What pricing advantage do containers on Vercel have?

Active CPU pricing — no charge for idle time

---

Summary Mind Map

Vercel Backends
├── Python (GA)
│   ├── FastAPI, Flask, Django
│   └── PyPI + Vercel SDKs
├── Containers
│   ├── Any language
│   ├── Custom OS libraries
│   └── Dockerfile deployment
└── Daemons
    ├── Always-running workers
    ├── Pull-based workloads
    └── Configured in vercel.toml