Canonical URL: [https://blog.1001020.xyz/](https://blog.1001020.xyz/)
Suggested cover image: use a recent image from [https://blog.1001020.xyz/gallery](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 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:
The gallery is a first-class part of the site, not just a media folder. You can browse it here: AI Gallery on 1001020
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.
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:
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.
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.
The site now ships with the boring but important search plumbing:
sitemap.xml
image-sitemap.xml
robots.txt
One article that explains part of the agent workflow direction is here: Agent Harness Loop and Graph Engineering 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: I am still iterating on the publishing workflow, but the core system is now stable enough to share.