If you run web apps or high-traffic sites, you know the old trade-off. On one side, a dedicated server (a VPS, an AWS EC2 instance) gives you flexibility, and in return you babysit databases that strain and hosting bills that climb. On the other, pure static (the JAMstack approach) is fast and cheap, but you rebuild the whole site every time a piece of content changes. For years you picked your pain.
In 2026 that line has blurred. Edge computing, popularised by Cloudflare, plus the flexibility of the Astro framework, has produced a third option: serverless that genuinely costs close to nothing and starts instantly.
This is the architecture underneath EmDash, Cloudflare's open-source CMS. One honest note before we go further: EmDash itself is still an early developer preview (v0.1.0), so treat it as a direction, not a production default. We unpacked what it is and where it sits in our look at EmDash as a WordPress alternative. This article is about the layer below it: the Cloudflare stack (Workers, R2, D1) that makes a modern app cheap to run and fast by default, and how it compares to the serverless model most teams already know.
Cloudflare Workers vs AWS Lambda: the end of the cold start
Serverless has long promised a simple deal: you pay only for what you run, and you stop thinking about machines. The catch, in the traditional model that AWS Lambda made famous, is the cold start.
What a cold start actually is
A cold start (the latency a serverless function adds when it has not run recently) happens because the platform has to spin up a fresh execution environment. In the container model behind Lambda, when a function has been idle, the provider boots a full virtualised container before your code runs. The first user after an idle period waits for that boot. Depending on the runtime and configuration, that wait is a documented limitation of the virtual machine model, and it is exactly the kind of latency you do not want on a checkout page or an API call.
V8 isolates: warm by design
Cloudflare Workers change the technical model rather than optimise the old one. Instead of one container per function, Workers run inside V8 isolates: the same lightweight sandboxing technology that keeps the tabs in your Chrome browser separate. A single runtime instance manages hundreds or thousands of isolates and switches between them, with each one's memory sealed off from the rest.
Cloudflare's own documentation is direct about the effect: this model "eliminates the cold starts of the virtual machine model", and any given isolate can start "around a hundred times faster than a Node process on a container or virtual machine", while consuming an order of magnitude less memory on start-up.
[ AWS Lambda ] : Request --> boot virtualised container --> cold-start latency --> run [ Cloudflare ] : Request --> V8 isolate (already warm) --> runs, no cold start
The practical result: your code runs across Cloudflare's network of 337 cities in 100+ countries, close to your users, without paying a start-up tax on the first request.
A cold start is the tax you pay for spinning up a machine. Workers never spin one up.
What is a cold start, and why don't Cloudflare Workers have one? A cold start is the delay a serverless function adds when it has to boot a fresh execution environment after being idle. Cloudflare Workers avoid it because they run in V8 isolates that are already loaded in a running process, so there is no container to boot per request.
Compute, data and storage on the edge: the full triptych
A very fast function is worthless if it then waits on a database sitting on the other side of the planet. This is where the Cloudflare set goes further than a compute layer alone, and where it pays to look past the one-line summary: it covers data and storage on the same network.
D1: distributed SQL next to your code
D1 is Cloudflare's native SQL database, built on SQLite. Where traditional PostgreSQL or MySQL setups centralise data in one region, D1 is designed to keep data close to the Workers that read it, so queries resolve in milliseconds instead of crossing continents. On the free plan it covers 5 million rows read per day, 100,000 rows written per day, and 5 GB of storage, which is generous headroom for a content site or a small app.
R2: object storage without the egress tax
If you have used AWS S3, you know the pattern: storing files is cheap, but retrieving them (the egress fees, charged on data leaving the store) is where the bill quietly grows. R2 removes that line entirely. Cloudflare charges no egress fees on R2: whether your users download 10 MB or 10 TB of images, you pay for stored space, not for serving it. The free tier covers 10 GB of storage per month. For any media-heavy site, that single difference reshapes the cost model.
Does R2 charge egress fees? No. R2 provides free egress bandwidth when you serve data directly from it. You are billed for storage and operations, not for data leaving the store, which is the main structural difference from S3 on cost.
Scale-to-zero: pay only when you work
For a developer or a startup, the financial model is the part that looks almost too good. It is the principle of scale-to-zero.
If your site or app gets no traffic overnight, your Workers do not execute, your D1 database sits idle, and your consumption is zero. There is no always-on instance ticking over a bill while nobody visits. The free tiers are wide enough that many side projects and MVPs run all year without paying: 100,000 Worker requests per day, 5 GB on D1, 10 GB on R2. You move to paid usage when real traffic arrives, not before.
What does scale-to-zero mean? It means infrastructure that consumes (and costs) nothing when there is no traffic, and scales up automatically when requests come in. You are not paying for idle capacity, unlike an always-on server or a reserved instance.
Case study: migrating WordPress to Cloudflare EmDash
This is not a lab benchmark. brixio.io runs on EmDash and Astro, on Cloudflare's infrastructure.
Infrastructure costs stay minimal for a content site like ours, and traffic spikes are absorbed with no server configuration on our side, no machine to oversize, no cache layer to bolt on.
Astro plus Cloudflare: the right coupling
To tie these pieces together cleanly, the Astro framework is the natural fit. Through its native Cloudflare adapter, Astro runs directly inside Cloudflare's runtime (workerd), so the same project serves both static pages and dynamic logic.
You build hybrid:
- Pure content pages (articles, landing pages) are generated as lightweight static HTML through Astro's Islands Architecture (the pattern that ships zero JavaScript by default and isolates interactive components into their own "islands").
- Dynamic routes (an API, authentication, a query to D1) are turned into Cloudflare Workers automatically at build time.
You get the speed of static for SEO, where pages need to be light and crawlable, and the power of serverless for the parts of the app that genuinely need to run code. One codebase, one deploy, two execution modes. Building the custom application logic that runs on top is exactly what our custom application development delivers.
Is Astro plus Cloudflare good for SEO? Yes. Astro ships static, lightweight HTML by default, which helps crawlability and Core Web Vitals, while dynamic features run as Workers without forcing the whole page to be client-rendered.
Conclusion: the sensible technical choice
Managing Linux servers, patching VPS instances, and tuning Nginx configurations is becoming a legacy skill for basic web deployment. Moving your logic to the edge with Astro and Cloudflare lets you stop maintaining machines and start shipping: performance is high by default, scaling is handled for you, and fixed costs fall close to zero when traffic does.
The hard part, as ever, is not the launch. It is operating the result over time: tuning Cloudflare, keeping it secure, and keeping it fast under real traffic. That is the part Brixio does.
Keep going in this series
- The CMS itself: what EmDash is, and whether it is a credible WordPress alternative. (Article 1.)
- Security and architecture: moving your code onto a third party raises real security questions. How Cloudflare's isolate model protects applications, and how it reshapes CMS security, in depth. Read WordPress plugins vs Cloudflare isolates: the security model. (Article 3, coming soon.)
Frequently asked questions
Lambda boots a container for an idle function, which adds latency to the first request after a quiet spell. Workers skip that step: they run in V8 isolates inside a live process, which Cloudflare says "eliminates the cold starts of the virtual machine model".
For many workloads, yes, and the structural reasons matter more than the headline rate: Workers scale to zero (no traffic, no cost), and the surrounding storage (R2) has no egress fees, which is often where an AWS bill grows. The Workers free plan covers 100,000 requests per day, enough for most MVPs and side projects to run at no cost.
No traffic, no execution, no charge. Your Workers and D1 database stay dormant until a request arrives, so an overnight lull costs nothing instead of billing for idle capacity.
No. Serving data out of R2 is free; you pay only for what you store and the operations on it. That egress line is usually what inflates an equivalent S3 bill.
Yes. Pages are delivered as static HTML by default, so they stay light and easy to crawl, while only the genuinely dynamic parts run as Workers.
