Home / Devlog / forge-cms.dev is built with Forge

forge-cms.dev is built with Forge

forge-site meta deployment

The best proof that a framework works is using it yourself.

forge-cms.dev is a Forge application. Two content types — Post (this devlog) and DocPage (the documentation) — backed by SQLite on a Hetzner VPS. Caddy handles TLS automatically. The binary is ~15MB. The server costs €3.49 a month.

The stack

internet → Caddy (:443) → Forge binary (:8080) → SQLite

No container orchestration. No managed database. No CDN. A single VPS, a Caddyfile with one line, and a Go binary with everything embedded.

What Forge handles automatically

Every post on this devlog has:

  • A canonical URL
  • Open Graph and Twitter Card meta tags
  • A breadcrumb JSON-LD block
  • An entry in /sitemap.xml
  • An entry in /llms.txt
  • A /aidoc endpoint at /devlog/{slug}/aidoc
  • An entry in /devlog/feed.xml

None of this required configuration. It came from registering the Post type as a Forge module with SitemapConfig{}, Social(OpenGraph, TwitterCard), Feed(FeedConfig{...}), and AIIndex(LLMsTxt, LLMsTxtFull, AIDoc).

The admin workflow

There is no admin UI yet — that is Phase 2. Content is created via the Forge REST API using a Bearer token. A .http file in the repo covers the full workflow: create draft, update, publish.

When forge-admin ships, this site will be the first to use it.

Why this matters

A framework that its own author does not use in production is a framework with unknown gaps. Every rough edge on this site is a signal for a framework improvement. The devlog posts you are reading were written against the real API, rendered by the real templates, served by the real binary.

This is what it means to eat your own cooking.