Step-by-Step Study Guide
Step 1: Understand the Problem Fluid Solves
The Old Way of Thinking About Compute
Historically, compute evolved through distinct phases:
| Era | What You Did | Limitation |
|---|---|---|
| Physical hardware | Bought and swapped parts manually | Slow, expensive, manual |
| Bare metal rental | Rented servers for websites/databases | Still rigid |
| Cloud VMs | Requested any configuration on demand | Faster, but still too slow for agents |
| Fluid | Describe the work, machine forms around it | Instant, adaptive |
The Core Problem
Different workloads have different needs:
- How long they run
- How much memory they consume
- How much control they need over the environment
Previously, each workload type needed its own compute primitive, meaning developers spent time provisioning infrastructure instead of building features.
Key Insight: Iteration speed was limited by infrastructure provisioning, not by development speed.
Step 2: Understand What Fluid Is
The Simple Definition
Fluid is a single unified compute system that:
- Takes any workload
- Assembles the machine it needs
- Swaps configuration on the fly
- Absorbs burst capacity in real time
Think of it this way:
Old model: Work β Find the right machine β Fit your work to it
Fluid model: Describe the work β Machine forms around it
Scale Reference (to understand its significance)
- 15 million builds per day
- 25 million sandboxes per week
- 1 trillion requests per month
Step 3: Learn the Three Workload Types Fluid Handles
Each workload has a different "shape" of need:
π¨ Builds (Compute-Bound)
- Needs: Heavy CPU and memory
- Characteristic: Runs hard, finishes, done
- Machine type: Large, powerful VM
β‘ Functions (IO-Bound)
- Needs: Fast startup, specific code loaded instantly
- Characteristic: Waits on databases or external services
- Machine type: Small VM, starts immediately on request
π§ͺ Sandboxes (Flexibility-Bound)
- Needs: Whatever configuration the task requires
- Characteristic: Unpredictable shape, needs attached storage
- Machine type: Variable, with Drive attached for user data
Key Concept: Instead of one request = one instance, many requests run on one instance. Work starts immediately, and you only pay for active CPU time, not idle waiting time.
Step 4: Learn the Three Core Components
Fluid is built from three distinct layers working together:
Component 1: Hive (The "Hardware" Layer)
What it does:
- Provisions isolated virtual machines for every workload
- Picks the right machine for each job
- Maintains isolation in a multitenant environment (multiple users, safely separated)
- Operates at global scale
- Provides one control-plane API for all products
Why it matters:
- Every Vercel product builds on the same foundation
- No team maintains separate infrastructure
- Provisions a full VM in milliseconds
Hive = The engine that spins up the right machine, instantly and safely
Component 2: Fluid Images (The Environment Layer)
What it does:
- Lets you push your own custom OS image instead of using a fixed cloud OS
- Converts your image into VHS format (Vercel Hive Snapshot)
- Enables the machine to resume rather than cold boot
- Result: custom environment ready in milliseconds
Key distinction:
| Before | With Fluid Images |
|---|---|
| You ran the OS the cloud gave you | You choose and push your own image |
| Cold boot every time | Resume from snapshot |
| Slow startup | Millisecond readiness |
VHS (Vercel Hive Snapshot) is the optimized format that makes this possible β the same technology powers both Dockerfile deploys and sandbox custom images.
Fluid Images = Your environment, your rules, ready instantly
Component 3: Vercel Drives (The Storage Layer)
What it does:
- Provides portable, durable storage that travels with the workload
- Storage is not tied to any single machine
- Files persist even when the compute underneath is swapped or destroyed
- Enables "pick up exactly where you left off"
Why this is critical:
Old model: Files live ON the machine β machine dies β files gone
Fluid model: Files live IN the Drive β machine dies β Drive reattaches to new machine
Current status: Attached to sandboxes today (private beta), expanding to all of Fluid.
Vercel Drives = Persistent memory that outlives any single machine
Step 5: Understand How the Three Components Work Together
Here is the complete flow when a workload arrives:
Workload arrives
β
Fluid identifies its "shape" (compute-bound? IO-bound? flexible?)
β
Hive provisions the right VM (usually already warm β instant)
β
Fluid Image boots on top (your environment, resumed from VHS snapshot)
β
Vercel Drive connects (your files, exactly where you left them)
β
Work runs β you pay only for active CPU time
β
Workload ends β Drive persists β machine is released
Step 6: Understand Why This Matters for AI Agents
AI agents have uniquely demanding requirements that expose the limits of traditional compute:
| Agent Requirement | Why It's Hard | How Fluid Solves It |
|---|---|---|
| Needs the right machine immediately | Standard VMs provision too slowly | Hive keeps warm VMs ready |
| Runs untrusted code | Security risk in shared environments | Full VM isolation, stronger than containers |
| Brings its own tools/environment | Can't use a fixed OS | Fluid Images with custom environments |
| Spins up and tears down constantly | State would be lost between tasks | Vercel Drives persist state independently |
Core Agent Principle: An agent's state must outlive the compute. Fluid makes this possible by decoupling storage from machines.
Step 7: Understand the "One System" Advantage
Why unification matters:
Separate systems: One unified system (Fluid):
βββββββββββββββ βββββββββββββββββββββββββββ
β Build infra β β β
βββββββββββββββ€ β Improvement in: β
β Function β vs. β β’ Boot time β
β infra β β β’ Isolation β
βββββββββββββββ€ β β’ Scheduling β
β Sandbox β β β’ Caching β
β infra β β β
βββββββββββββββ β β Benefits ALL of: β
β Functions + Sandboxes β
Improvement in one β + Builds simultaneouslyβ
doesn't help others βββββββββββββββββββββββββββ
One improvement = universal benefit across all products
New compute shapes can be added without rebuilding the foundation, preventing the "separate primitives that drift apart" problem.
Summary: The Complete Mental Model
FLUID COMPUTE
βββββββββββββββββββββββββββββββββββββββββββββββ
"Describe the work β The machine forms around it"
βββββββββββββββββββββββββββββββββββββββββββββββ
β HIVE β Provisions the right VM β
β FLUID IMAGES β Provides your environment β
β VERCEL DRIVES β Persists your state β
βββββββββββββββββββββββββββββββββββββββββββββββ
Workload types it handles:
β’ Builds β Compute-heavy, CPU/memory focused
β’ Functions β IO-bound, small VM, instant start
β’ Sandboxes β Flexible shape, Drive attached
Why it matters:
β’ Developers iterate on features, not infrastructure
β’ Agents get secure, instant, stateful compute
β’ One system = improvements benefit everything
Quick Self-Check Questions
- What were the three limitations of traditional compute that Fluid addresses?
- What does VHS stand for and why does it matter?
- Why is storage being decoupled from compute so important for agents?
- What is the pricing advantage of Active CPU pricing?
- How does a build differ from a function in terms of what machine it needs?
- Why does improving Hive benefit functions, sandboxes, AND builds simultaneously?