Serverless websites on Cloudflare

“Serverless” sounds like a buzzword, and a slightly silly one — of course there’s a server somewhere. But the idea behind it is genuinely simple, and once it clicks you may never want to manage a web server again. This very blog runs this way: no server, no monthly bill, and it loads fast from anywhere in the world. Here’s how that works.

The old way: a computer you rent and babysit

Traditionally, putting a website online means renting a server — a computer in a data centre that’s always switched on. It runs software (a web server, maybe a database), and every time someone visits, that computer builds the page and sends it back.

That works, but it’s a lot of babysitting: you install updates, patch security holes, keep it from falling over when traffic spikes, and pay for it every month whether ten people visit or none. And it lives in one place — so a visitor on the other side of the planet waits while the data travels back and forth.

The new way: your site is just files, copied everywhere

A serverless static site flips this around. Instead of a computer building each page on demand, your whole site is turned into plain files ahead of time — the HTML, CSS, images and scripts a browser needs. Those files are then handed to Cloudflare, which copies them to hundreds of locations around the world. When someone visits, they get the copy from the city nearest them, almost instantly.

There’s no server for you to run. Nothing to patch, nothing that crashes at 3am, nothing to scale. You look after the content; Cloudflare looks after delivering it.

Build once, deploy, and Cloudflare does the hard part — delivering your files from wherever the visitor happens to be.

“Lives everywhere” — what that actually means

The magic word is edge. Cloudflare has computers in hundreds of cities (its “edge network”, also called a CDN). Your site’s files sit on all of them. So there isn’t one website in one place that everyone queues for — there are copies close to everyone, all at once.

A visitor in Tokyo is served from Tokyo — not from one faraway server. That's why it feels instant everywhere.

Because the files are just sitting there ready, a sudden rush of visitors is a non-event — Cloudflare serves them the same cached files, whether it’s ten people or ten million. No “hug of death”, no scrambling to add servers.

Old way vs new way, side by side

Same website online — very different amount of babysitting.

“But my site needs to do things”

Fair — pure files are great for blogs, portfolios, docs and landing pages, but what about a contact form, a login, or live data? That’s where the “serverless” part earns its name. Cloudflare lets you add small functions called Workers: tiny bits of code that also run on that same global edge, but only for the moment a request needs them — no server sitting idle in between. Your pages stay static and instant; a Worker handles the occasional dynamic bit (send the form, check the stock, return some JSON) and then it’s gone.

So the mental model is: static files for everything you can, a sprinkle of Workers for the parts that must be live.

What about Laravel or Magento?

This is the question I get from every developer friend: “can I run my Laravel app — or Magento — this way?” The honest answer is no, not this way — but Cloudflare still has a job to do.

Serverless-static works because the pages can be built ahead of time into files. Laravel and Magento are the opposite: they build each page on request, using PHP and a database (and Magento also leans on Redis, OpenSearch, Varnish, cron and queues). Cloudflare’s serverless functions run JavaScript, not PHP — so these frameworks don’t run on it. Here’s where they actually live:

• Magento / Adobe Commerce — in production it runs on a real server or containers (a cloud VM, managed Magento hosting, or Adobe Commerce Cloud); locally you’d develop it on a stack like Warden . Either way Cloudflare’s role is the edge in front: CDN caching, WAF, DDoS protection, TLS. It makes the store faster and safer, but it doesn’t host the application.
• Laravel — also needs a PHP backend. You can go serverless-ish with it, but through AWS Lambda (Laravel Vapor), not Cloudflare Workers. A common Cloudflare-friendly pattern is to split it: a static or single-page frontend on Cloudflare, talking to a Laravel API that runs on a server.

The rule of thumb that keeps it all straight:

• A site you can pre-build → serverless static, entirely on Cloudflare.
• A few live actions → add Workers (JavaScript) at the edge.
• A full app that builds pages on demand → it runs on a server; Cloudflare goes in front of it, not instead of it.

Cloudflare is growing beyond this too — Containers and Hyperdrive (which connects to a normal Postgres or MySQL database) mean heavier workloads are increasingly possible on the platform. But for a full Magento today, “a fast, protective layer in front of a proper backend” is the right — and boring — answer.

How you’d actually do it

You don’t need to touch a server at any point:

1. Build your site into files — with a static-site generator like Hugo, Astro or Eleventy, or even hand-written HTML.
2. Put it on GitHub (or GitLab).
3. Connect the repo to Cloudflare — Pages or Workers. It builds your site and deploys it on every push.
4. Get a free URL, then point your own domain at it. Done.

From then on, publishing is just git push. Cloudflare rebuilds, copies the new files worldwide, and your visitors — wherever they are — get the update in seconds. That’s the whole trick, and it’s exactly how the blog you’re reading is served.