Cloudflare, Workers, D1, R2, Vectorize, edge
How I built this entire site on the Cloudflare edge
This site is a real application: a blog, curated links with semantic search, forms, a control panel, and an MCP server, all running on the Cloudflare edge with no traditional server in between.
Published on 2026-06-30 · Updated on 2026-06-30
Case summary
- Problem
- I wanted a portfolio that was also a real product (blog, curated links, semantic search, AI) and responded fast in any region, without me maintaining a server or paying for idle capacity.
- Context
- A personal project treated as a lab for what I recommend to clients. Every choice had to hold up in production, not just in a demo.
- Decision
- Run everything on the Cloudflare edge: Astro SSR on Workers, with D1, R2, KV, Vectorize, and Workers AI as native pieces, instead of standing up a traditional server and database.
- Result
- An architecture with no server to maintain, fast global response, and low operating cost. The site became living proof of the specialty I offer.
When I decided to rebuild my site, the easy temptation was to spin up a WordPress or a Next app on a VPS and move on. But I wanted the site itself to answer a question I hear from clients almost every week: can you run a real application, with a database, search, and AI, without maintaining a server and without paying for idle capacity? The answer I argue for is yes, at the edge. So I built exactly that and let the site be the demonstration.
What this site actually does
People tend to treat a personal site as a static page. This one does much more: it serves prerendered marketing pages, a blog backed by a database, a curated links section with semantic search and connections between pieces of content, contact and newsletter forms, a control panel with authentication, and an MCP server that exposes read-only tools to AI agents. Each of those pieces has a different demand for latency, state, and cost, and that is what made the project a good architecture test.
Why edge, and why Cloudflare
The Worker runs close to whoever visits, with near-instant startup, so the first response is already fast in any region. But compute was only part of the decision. What weighed more was having database, storage, cache, vectors, and AI right there as native pieces, accessed through bindings, without me standing up and maintaining a separate service for each one. Instead of stitching five providers together, I stay inside a single runtime.
Each piece in its place
Most pages are prerendered to static HTML at build time, and only the routes that need live data run on-demand SSR: APIs, blog, links, and the panel. D1, which is SQLite at the edge, holds the blog posts and the curated links. R2 holds the assets, with no egress cost. KV holds the panel’s authentication sessions. Vectorize indexes the embeddings of posts and links, which lets the site suggest semantic connections between content. Workers AI generates those embeddings and runs the AI features. And there is an MCP server on the Worker itself, plus a WebMCP tool in the browser, so agents can discover what exists here without scraping the page.
The honest trade-offs
The edge has limits, and it would be dishonest to sell it as a silver bullet. D1 is still young and has size and write limits that would matter in a write-heavy operation, so it shines on reads, which is my case here. Debugging at the edge is different from opening a terminal on a server: you lean more on logs and observability than on attaching a profiler. The Worker has a CPU ceiling per request, which forces heavy work out of the response path. None of that got in my way here, but those are exactly the questions I ask before recommending this path to a client, because the answer changes with the workload.
What this proves
Recommending architecture is easy on a slide. What gives the recommendation weight is running what you argue for, with the scars that only show up in production. This site is that argument: every choice you see here I have lived end to end, with the real problems that come with it.
Traditional approach vs. edge
| Aspect | Traditional server (VPS/AWS) | Cloudflare edge |
|---|---|---|
| Compute | Always-on process, paid even when idle | On-demand Workers, no server to maintain |
| Database | Managed Postgres/MySQL, with connection and fixed cost | D1 (SQLite at the edge), close to the request |
| Storage | S3 with egress cost | R2 with no egress cost |
| Semantic search | Separate vector service to stand up and maintain | Native Vectorize, accessed through a binding |
| AI | External model endpoint and keys to manage | Workers AI in the same runtime |
| Global latency | One region, slow for anyone far away | Response close to the user on Cloudflare's network |
| Deploy | Pipeline and machine to configure | Push to the branch and automatic build |
Stack and environment
- Astro 7 (SSR) on Cloudflare Workers
- D1 (SQLite at the edge) for blog and links
- R2 for assets, no egress
- KV for panel sessions
- Vectorize for semantic search
- Workers AI for embeddings and AI
- MCP server at the edge and WebMCP in the browser
- Wrangler and automatic deploy (Workers Builds)
In one sentence
Instead of describing the architecture on a slide, I let the site be the implementation: a real application, with a database, search, and AI, running entirely on the Cloudflare edge.
The hardest proof to fake that something works is running the very thing you recommend.