How I Built a Serverless Blog on Cloudflare Workers with KV and R2

Canonical URL: https://blog.1001020.xyz/ Suggested cover image: use a recent image from https://blog.1001020.xyz/gallery I have been building a small publishing system called 1001020, a serverless blog and AI gallery running on Cloudflare Workers. The live site is here: 1001020 — AI Gallery & Cloudflare Experiments The goal was not to build another static blog generator. I wanted something that could publish articles, serve an image gallery, manage uploaded assets, expose structured sitemaps, and stay operational without a traditional server. The basic architecture The whole public site runs on Cloudflare Workers. Articles, settings, comments, gallery metadata, and telemetry live in Cloudflare KV. Managed images are stored in R2 and served through a dedicated image domain. The main pieces are: Cloudflare Workers for request routing and rendering Cloudflare KV for article and site metadata Cloudflare R2 for managed image uploads A theme system for different frontend layouts XML sitemap and image sitemap generation A small local AI drafting tool for preparing and publishing content The gallery is a first-class part of the site, not just a media folder. You can browse it here: AI Gallery on 1001020 Why Workers instead of a conventional backend? For this project, Workers are a good fit because the workload is mostly request routing, HTML generation, metadata reads, and small API writes. A conventional server would work, but it would add deployment and maintenance overhead that I did not need. Cloudflare Workers also make it easy to keep the app close to the edge while still handling dynamic behavior. The blog can render pages server-side, expose APIs, and support admin operations without a separate Node or container deployment. KV as the content store The project stores persistent content in KV using explicit keys for articles, gallery records, settings, telemetry, comments, newsletter subscribers, and other small datasets. This shape works well for a personal publishing system because the access pattern is simple: read the article index read individual article records write admin updates render HTML or markdown responses regenerate sitemap output from current content The main tradeoff is that KV is not a relational database. I keep data models small and explicit, and avoid pretending it can do arbitrary query workloads. R2 for images Images are uploaded as managed assets and served from R2. Article content can reference those managed image URLs, and the system tracks image references so unused assets can be identified and cleaned up. That part matters because image-heavy blogs tend to accumulate stale files quickly. Treating image references as part of the content model keeps the gallery and article system easier to maintain. SEO basics that are built in The site now ships with the boring but important search plumbing: sitemap.xml image-sitemap.xml robots.txt server-rendered article content image dimensions for layout stability canonical article URLs Google Search Console verification token injection through the admin settings page One article that explains part of the agent workflow direction is here: Agent Harness Loop and Graph Engineering What I learned The biggest lesson is that a serverless blog should not be treated as a toy static page. Once publishing, images, metadata, admin operations, analytics, and sitemaps enter the picture, the system starts to look like a small CMS. Cloudflare Workers can handle that shape well, but only if the storage model stays simple and the routes remain deliberate. For 1001020, the result is a compact publishing stack that can run globally without a traditional backend server: live site: https://blog.1001020.xyz/ AI gallery: https://blog.1001020.xyz/gallery example article: https://blog.1001020.xyz/article/agent-harness-loop-graph-engineering I am still iterating on the publishing workflow, but the core system is now stable enough to share.