Monolith - Cloudflare-Native Blog CMS on Workers, D1, and R2

Yes, when deployed on the default Cloudflare path.

The app uses Cloudflare Pages for the frontend, Pages Functions for proxying, Workers for API compute, D1 for relational data, and R2 for files/backups. That means there is no VM, no Docker daemon, no OS patching, and no database server to administer.

The tradeoff is platform coupling. The app depends on Cloudflare bindings such as DB, BUCKET, AE, and Pages API_BASE.

Not as shipped.

The repository does not include a Dockerfile or compose stack. It is designed around Wrangler and Cloudflare deployment.

You can run development locally with Node and Wrangler, but production self-hosting means deploying into your own Cloudflare account, not running a portable container stack on a VPS.

Required for the normal Cloudflare deployment:

Optional or feature-specific:

Minimum production:

export ADMIN_PASSWORD='replace-with-a-strong-password'
export JWT_SECRET="$(openssl rand -base64 32)"
npx wrangler login
npm run deploy:cloudflare

Core bindings in server/wrangler.toml:

Common optional secrets:

npx wrangler secret put TURNSTILE_SECRET --name monolith-server
npx wrangler secret put RESEND_API_KEY --name monolith-server
npx wrangler secret put CLOUDFLARE_API_TOKEN --name monolith-server
npx wrangler secret put REACTION_SALT --name monolith-server

If using adapters instead of Cloudflare defaults, configure DB_PROVIDER, STORAGE_PROVIDER, and the matching Turso/Postgres/S3 variables.

The default path can run on Cloudflare services: Pages, Workers, D1, R2, and optional Analytics Engine.

External databases are not required for the default deployment.

They are adapter options. You can move the database to Turso or PostgreSQL, and object storage to S3-compatible storage, but doing that makes the deployment less Cloudflare-contained.

Hugo and Jekyll generate static files. They are excellent when Git is the publishing workflow and you want minimal runtime state.

Monolith is dynamic. It keeps posts, settings, comments, reactions, media, pages, and analytics in runtime services and exposes a browser admin console.

So the comparison is:

Monolith is best described as a database-backed blog CMS for Cloudflare, not a traditional static-site CMS.

It has a Markdown-first writing experience, but the source of truth is not a folder of .md files in Git. Posts and pages are stored in the database through the app’s storage adapter: D1 by default, or Turso/PostgreSQL if you choose another provider.

That puts it somewhere between:

So I would not treat it as a direct replacement for a Git-backed Hugo workflow. I would treat it as a dynamic blog CMS that happens to use Markdown as the authoring format.

WordPress and Ghost are mature CMS/blog systems built around a server process and database.

Monolith is much younger and more Cloudflare-specific, but avoids running a VPS or container host. It is attractive if you want a modern edge-native blog CMS and are comfortable with Wrangler, D1, R2, and Cloudflare platform limits.

WordPress still wins for plugin ecosystem. Ghost still wins for polished publication/member workflows. Monolith wins when the Cloudflare-native architecture is the feature.

CloudflareBase is a Firebase-style backend platform on Cloudflare.

Monolith is an actual blog/CMS application.

The relationship is:

CloudflareBase = platform/backend layer for building apps
Monolith = finished publishing app built directly on Cloudflare primitives

Both are part of the same broader pattern: Workers plus Cloudflare storage primitives can replace a local server stack for certain web apps.

Hono is a small TypeScript web framework commonly used on edge runtimes such as Cloudflare Workers.

In Monolith, Hono is the backend router layer. It receives requests such as:

GET  /api/posts
GET  /api/posts/:slug
POST /api/auth/login
POST /api/admin/posts
PUT  /api/admin/posts/:slug
GET  /rss.xml
GET  /sitemap.xml

Why it fits here:

• it is lightweight enough for Workers;
• it gives clean routing and middleware without Express-style Node server assumptions;
• it works well with Web Fetch APIs, which Workers use natively;
• it keeps the backend portable across edge-like runtimes more easily than a full Node server framework.

So Hono is not the CMS. Hono is the HTTP framework that lets the Worker expose the CMS API.

They solve different layers of the stack.

Hono is a web framework. It gives the Worker a clean way to define routes, middleware, request parsing, responses, and API endpoints.

Better Auth is an authentication framework. It handles users, sessions, sign-in methods, OAuth providers, organization/team models, password flows, and auth-related database tables.

So they are not competitors:

Monolith currently uses Hono, but it does not use Better Auth. Its admin authentication is simpler: admin password plus JWT session, with optional Turnstile.

If Monolith wanted multi-user editing, invitations, editor/admin roles, Git commit attribution, OAuth login, or per-user publishing permissions, Better Auth would be a natural piece to add. Hono would still remain the API framework underneath.

No.

The Vite PWA setup generates a service worker, precaches frontend assets, caches /cdn/* images with a cache-first strategy, and uses network-first caching for non-admin API calls.

That means Monolith can be useful offline for already-loaded public reading paths:

• the app shell can load after a previous visit;
• cached images can still render;
• some previously fetched public API responses may be available if the network is down;
• installed-PWA behavior can make the site feel app-like on mobile/desktop.

But the admin CMS is not offline-first.

The service worker intentionally excludes admin/auth routes from runtime API caching. Editing, publishing, media uploads, comments moderation, backups, login, and settings changes still need the Worker API and database/storage services online.

So the short version is:

offline reading cache: yes, partly
offline CMS editing/publishing: no

Your target architecture is:

authenticated users edit locally in a PWA
PWA syncs Markdown files to Git
PWA uploads images to Cloudflare R2
Astro builds a static site from .md files
Cloudflare Pages deploys the generated static site

That is a solid architecture, but it is not Monolith’s current architecture.

Monolith already has some useful pieces:

But the parts that make your desired workflow safe and static are missing:

So Monolith is maybe close in editor feel, but far in publishing model.

The current model is:

React admin editor -> Worker API -> D1 database + R2 media -> dynamic Cloudflare site

Your desired model is:

PWA editor -> local IndexedDB drafts -> Git commits/PRs with .md files -> Astro static build -> Cloudflare Pages
                               \-> R2 media uploads -> image URLs in Markdown

That is closer to a Git-backed static CMS than to Monolith’s current database-backed CMS.

I would split it into three surfaces.

First, the editor PWA:

• stores drafts, images-to-upload, frontmatter, and sync state in IndexedDB;
• works offline for writing and previewing Markdown;
• has an explicit “Sync” button instead of relying only on browser background sync;
• shows per-file sync status: local draft, uploaded asset, committed Markdown, build pending, live;
• never treats “saved locally” as “published”.

Second, the authenticated sync API:

• uses real user accounts and roles, probably Better Auth rather than a single shared admin password;
• uploads images to R2 through signed URLs or a Worker upload endpoint;
• returns stable public R2 URLs for Markdown insertion;
• writes Markdown/frontmatter to a Git branch through GitHub/GitLab APIs or a GitHub App;
• creates pull requests for non-admin users, while trusted admins may commit directly;
• only allows writes under approved paths such as src/content/blog/ and public/metadata/;
• records audit events: who changed what, when, and which commit/build was produced.

Third, the static build path:

• Astro reads committed .md or .mdx files from Git;
• images referenced in Markdown point to R2 public URLs or a Cloudflare image proxy;
• Cloudflare Pages builds on commit or deploy hook;
• rollback is normal Git rollback: revert commit or restore previous branch state;
• production output remains static, so readers do not depend on the CMS database being online.

That gives a strong separation:

editing system can be dynamic
published site stays static
Git remains the durable content history
R2 stores large binary assets
Cloudflare Pages serves the final site safely

This would be a different product from Monolith, but Monolith provides useful reference code for the editor, Markdown preview, R2 media handling, Workers API shape, and Cloudflare deployment ergonomics.

Not directly.

Monolith does not edit the files of an existing Cloudflare Pages static site. It does not open your Pages project’s Git repository, change Markdown files, commit to Git, and trigger a Pages rebuild.

Instead, Monolith deploys its own React frontend to Pages and stores content in the backend database. Its “pages” feature means CMS-managed pages stored in the pages database table, written in Markdown and served through Monolith’s routes such as /page/:slug.

That is a very different workflow from:

edit content/posts/example.md
git commit
git push
Cloudflare Pages rebuilds the static site

If your goal is to keep the current static Pages site and edit its .md files from a UI, Monolith is not the right fit as-is. You would want a Git-backed CMS such as Decap CMS, Pages CMS, TinaCMS, or a custom GitHub/GitLab-editing workflow.

Markdown-centered: yes.

Git-backed: no, not in the current architecture.

Monolith stores content as text in the database for posts and pages. The editor is Markdown-oriented, public rendering turns Markdown into HTML, and importers understand Markdown/frontmatter from Hugo, Hexo, Jekyll, and other systems.

But after import, the canonical copy lives in the configured database:

D1 / Turso / PostgreSQL = content source of truth
R2 / S3                 = media and backup object storage
JSON / R2 / WebDAV      = backup/export paths
Git                     = app source code, not content source of truth

So backup is JSON/R2/WebDAV-centered, not Git-centered.

You could build a Git export pipeline around Monolith’s backup JSON or admin API, but that would be an extra integration. It is not the default publishing model.

The safe local checks passed:

npm ci                      passed
npm run build               passed
npm run check               passed
PWA service worker build    passed

The runtime doctor correctly failed because server/.dev.vars was missing. That file would need at least ADMIN_PASSWORD and JWT_SECRET for local development.

I did not create that file in the repo and did not deploy to Cloudflare.