This is part of an ongoing series I am writing as I work my way through the modern web stack from a WordPress developer’s perspective. The series is aimed at WordPress veterans who, like me, have built things on the web for years and feel quietly behind the curve. The goal is broad literacy, not deep mastery. By the end you should be able to read any modern stack list and know what each piece is doing.
Each post comes with an audio companion (10-15 minutes, generated via NotebookLM) for gym or commute listening. Press play below if that suits you better than reading.
Hook
“Serverless” has been the most consistently misnamed concept in modern web development for about a decade. There are servers. There are absolutely servers. The word “serverless” describes what you do not see, not what does not exist. The first time someone explained it to me they used the word “magic” four times. I left more confused than I started.
“Edge” came along a few years later and made it worse. Edge functions, edge runtime, edge middleware, edge databases. Sometimes “edge” means “close to the user.” Sometimes it means “constrained runtime.” Sometimes it means both, and sometimes it means a Cloudflare marketing slide.
This module is the de-jargoning of both terms. What serverless actually is, what edge actually is, what they cost, where they fall apart, and how a WordPress developer should think about them.
Core Concept
Start with the model you already have. A WordPress request lifecycle goes: visitor hits the URL, Nginx routes to PHP-FPM, PHP boots the WordPress codebase, WordPress queries MySQL, PHP renders HTML, the response goes back. The server is always running. PHP-FPM keeps a pool of worker processes warm. The next request reuses those workers. Memory is shared. Database connections persist.
Serverless flips that. There is no always-running process. When a request arrives, the platform spins up a container, executes your code, returns the response, and tears the container down. The next request might land on a brand-new container or a recently-reused one. Your code has to assume nothing persists between requests.
Three things flow from that.
Pricing changes shape. You pay for invocations and execution time, not for the server. If you have ten requests an hour, you pay almost nothing. If you have ten million, you pay per request.
Cold starts exist. When a new container has to boot from scratch, the first request takes longer (200ms to several seconds). After a few minutes of idleness, the next request is cold again. This is the most visible serverless cost, and modern platforms have spent significant engineering effort minimising it (smaller runtimes, lazy-loading, persistent connections).
Long-running work is awkward. A serverless function typically has to finish within seconds (15-300s depending on the platform). If you need to process a large file, run a long job, or hold a WebSocket connection open for ten minutes, serverless is the wrong shape. Use a long-running runtime (Fly.io, Railway, a traditional VM) or a queue + worker pattern instead.
Edge, the Actually-useful Definition
“Edge” in 2026 means two related but distinct things.
Geographic edge. Your code runs in datacenters all over the world, close to your users. A request from Lisbon hits a server in Lisbon. A request from Tokyo hits one in Tokyo. The win is latency: a 30ms ping instead of 200ms.
Constrained runtime. Edge functions run in a lightweight environment (often based on V8 isolates instead of full Node containers). This makes them spin up faster (low single-digit milliseconds vs hundreds for traditional serverless) but limits what you can do. No filesystem access, no full Node API, only a subset of npm packages work. Cloudflare Workers, Vercel Edge Runtime, and Deno Deploy all use this model.
The two often go together: edge runtimes are designed to be deployed geographically because they are small enough to do so. But you can have one without the other. Vercel’s edge runtime runs everywhere but the runtime constraints are the bigger story for most developers.
The WordPress Analogue
Mental model: Serverless is to PHP-FPM what a coffee shop’s order-by-order kitchen is to a buffet line.
A WordPress server is the buffet line. It is always prepared, always running, ready for the next dish. You pay to keep it warm whether anyone is eating or not.
Serverless is the order-by-order kitchen. The kitchen is staffed (the platform handles infrastructure) but no one fires a pan until you order. The first order in a while waits longer (the first cold start). Many orders in parallel scale up cleanly. You pay per dish.
Edge is the same kitchen but it is in every neighbourhood instead of one location. Your dish travels less to reach you.
The Landscape
The main flavours of serverless and edge in 2026:
| Type | Examples | Cold start | Best for | Watch out for |
|---|---|---|---|---|
| Container serverless | AWS Lambda, Vercel Node Functions, Google Cloud Run | 200ms-2s | Full Node APIs, larger dependencies | Cold starts; long-running not allowed |
| Edge runtime (V8 isolates) | Cloudflare Workers, Vercel Edge, Deno Deploy | 1-50ms | Latency-sensitive routes, middleware | Limited Node API, smaller bundle limits |
| Container always-on | Fly.io, Railway, Render | None (always warm) | Long-running, WebSockets, full Node | Pay for idle time |
| Static + ISR | Vercel ISR, Next.js static export | None (pre-built HTML) | Content-heavy pages with occasional updates | Build times scale with site size |
| Serverless functions on edge data | Cloudflare Workers + D1/KV | 1-50ms | Read-heavy global apps | Constrained writes, limited query power |
Most modern apps mix several of these in one project. A Next.js app on Vercel might run:
- The marketing pages as static HTML (no runtime, served from CDN)
- The blog pages as ISR (regenerated on a schedule)
- The auth middleware on the edge runtime (V8 isolates, low latency)
- The dashboard data fetching as Node functions (full API access, longer cold starts)
- Background jobs on a separate platform (Fly.io with a queue, or a cron worker)
This composition is the actual modern stack. “Serverless or not” is rarely binary.
What This Changes for WordPress People
Three practical implications.
The first is that “where does this code run” becomes a deliberate decision per route, not a setting on the host. A login form might run on the edge for low-latency rate limiting; a checkout flow might run on a Node function because it needs Stripe’s full SDK. The platform makes this composable instead of all-or-nothing.
The second is that scaling stops requiring planning. WordPress sites that grow successful require capacity decisions: bigger VPS, load balancer, read replica. Serverless platforms scale invisibly until you hit a different limit (database connections, third-party API rate limits). The bottleneck moves to your data layer, which is why managed databases now ship connection poolers (covered in Module 6).
The third is that AI dev tooling assumes this model. Most AI-generated server code expects a serverless or edge-like runtime. If you ever have an AI agent write a feature, the code is likely to be shaped for serverless deployment. Knowing the constraints (no filesystem, stateless, short execution) helps you spot when the AI is producing code that will silently fail in production.
Watch Out
A handful of traps.
Stateless is a real constraint. You cannot store anything on the filesystem and expect it to persist. You cannot rely on in-memory caches across requests. Any state has to go to the database or a shared cache (Redis, Cloudflare KV). Code that “just works” in a traditional Node server can fail subtly in serverless because of this.
Connection pooling is mandatory. Each serverless invocation wants a database connection. Without pooling, you exhaust Postgres connection limits at modest traffic. Most managed databases (Supabase, Neon, PlanetScale) ship poolers. Configure them or pay for it later.
Cold starts can be hidden. A site that feels fast in your testing might serve cold starts to real users. Use synthetic monitoring (Vercel Analytics, Sentry Performance) to actually measure the p95 latency, not just the median.
Edge runtime feels like Node, but is not. A library you depend on might use a Node API that does not exist in the edge runtime. The error often shows up only at runtime, not build time. The Vercel and Cloudflare docs have compatibility tables; read them when picking which functions go on the edge.
Cost can spike on bot traffic. Pay-per-invocation pricing means a misbehaving bot, a scraper, or a malicious actor can run up your bill. Set spend caps if your platform supports them. Set per-IP rate limiting on your edge layer.
Going Deeper
If you want to internalise the serverless and edge models, a few resources.
YouTube, gym or commute friendly:
- “Serverless in 100 Seconds” and “Edge Functions in 100 Seconds” by Fireship. Tiny but well-framed.
- “Building on Cloudflare Workers” on the Cloudflare channel (~30 min). Useful even if you stay on Vercel; it sharpens the contrast.
Official docs worth bookmarking:
- Vercel Functions docs. The “Runtimes” page tells you exactly what you can do in Node vs Edge.
- Cloudflare Workers docs. The “Compatibility” pages are mandatory reading before you commit to Workers for anything non-trivial.
- AWS Lambda fundamentals. Read just the first chapter; it sets the conceptual baseline that every other serverless platform is reacting to.
Next post in the series brings containers back into the picture: Docker for WordPress developers, what it actually is, and when you genuinely need it.
Related
Leave a Reply