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

#ai #cloudflare #serverless #javascript

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: