About add-blog
A drop-in blog engine for Cloudflare Workers. Add it to any site and that site gets a public blog, an authenticated admin, and an MCP endpoint an AI agent can write through.
What it is
Most blog engines are a whole application you adopt. add-blog is meant to be a component you attach: one Cloudflare Worker, deployed once per site, that takes over two subdomains and gives that site a blog without the site having to know anything about how it works.
It is plain HTML, CSS and JavaScript. No framework, no bundler, no build step — the files in the repository are the files on the edge.
How it works
One Worker answers on two hostnames and behaves completely differently on each.
| Hostname | Who | What |
|---|---|---|
blog.mysite.com |
Everyone | The public blog. Anonymous, read-only, cached hard at the edge. |
blog-admin.mysite.com |
Editors | The editor, media library and write API, behind Cloudflare Zero Trust Access. |
blog-admin.mysite.com/mcp |
AI agents | A Model Context Protocol endpoint, authenticated via Access Managed OAuth. |
Splitting on hostname rather than a path prefix is the load-bearing decision.
Access terminates unauthenticated requests at the edge before the Worker runs,
and the public hostname returns 404 for every admin path
unconditionally. Authorization becomes a property of where things are deployed
rather than something the application has to keep getting right.
Where the content lives
- D1 — posts, tags, authors, revisions, settings and the audit log. SQLite at the edge.
- R2 — images and attachments, under content-addressed keys so an object at a given key never changes and can be cached for a year.
Markdown is the source of truth. It is rendered to HTML once, when a post is saved, so serving a page is one indexed query rather than a parse.
Why an MCP endpoint
The interesting half of this project. An agent connects once through Cloudflare Access Managed OAuth and can then list, search, draft, edit and publish posts — bound by the same role checks as the human whose identity it is using, and recorded in the same audit log.
One constraint shapes the whole tool surface: publishing is always its own explicit call. Creating and updating a post cannot change its status. An agent can never make something public as a side effect of anything else, so the worst outcome of a bad generation is a bad draft.
Status
This is the Phase 1 front end running on bundled sample content. The public pages, the admin and the MCP page are all real interfaces; the data behind them is not. The build-out is documented in the repository:
- README — overview and repository layout
- Architecture — routing, data model, caching, threat model
- HTTP API — the contract this front end already calls
- MCP server — transport, auth, tools
- Deployment runbook — D1, R2, DNS, Access
- Implementation plan — phases and open questions
Built to run on Cloudflare Workers with static assets. Deployed straight from
main — no build step in between.