Wiki and public docs

Every repo carries a wiki — markdown pages stored as a separate Git repository inside Forgejo. fremforge layers an opt-in public mirror on top: enable it once, and the same wiki content is published as anonymous-readable pages at frem.sh/<org>/<repo>/wiki, ready to share with customers, partners, or anyone who needs to read your project’s documentation without a fremforge login.

The two surfaces

Same URL, cookie-conditional routing at the edge. A signed-in collaborator still sees the Forgejo-native wiki with the edit button + history; an anonymous visitor sees the cleaner public docs render of the same content.

Enabling the public mirror

Org admin → Public docs (under the Content sidebar group). For each repo:

1. Tick Enabled.
2. (Optional) Drop a small CSS snippet into Custom CSS to brand the public render — header colours, font choices, accent lines. The textarea caps at 8 KB and the < character is rejected at submit (prevents </style> HTML injection from leaking into the rendered page; CSS doesn’t legitimately need <).
3. Save.

The public mirror goes live within a few seconds. Revert by un-ticking Enabled at any time — the route falls back to Forgejo’s native rendering, which means anonymous visitors see whatever Forgejo would have served (login for private repos, native wiki HTML for public repos).

Authoring

Public docs renders the same wiki content Forgejo stores — edit the wiki the normal way (the Wiki tab on the repo, Forgejo’s markdown editor, or by cloning <repo>.wiki.git and pushing markdown). There is no separate authoring surface. What you write is what the public sees.

Supported features:

• GitHub-Flavored Markdown via marked.
• Mermaid diagrams. ```mermaid code fences render client-side via mermaid.min.js (~3 MB, served same-origin from /static/lib/, immutable-cached at the Bunny edge).
• Syntax highlighting for code fences via Prism (also same-origin).
• Print to PDF. Pure print CSS — Cmd+P / Ctrl+P produces a clean A4 / Letter render. No headless-Chrome dependency, no server-side PDF rendering.
• Sidebar navigation. Pages are listed alphabetically with the Home page surfaced first.

Not supported (yet):

• Per-page metadata or front matter
• Comments
• Custom domain pointing (e.g. docs.acme.com → the public mirror). Track this on the platform roadmap.

Privacy posture

The mirror is a read-only projection of an existing wiki. fremforge does not:

• Store anything customer-side beyond the per-repo opt-in row + the optional CSS snippet.
• Forward visitor IPs or cookies to Forgejo. The mirror’s Forgejo round-trip is a server-side fetch() with no client identifiers.
• Add tracking, ads, or third-party JS. The only same-origin scripts are mermaid + Prism.

Server-side render uses marked v18’s built-in HTML escaping — raw HTML in the wiki markdown is escaped at render. The mermaid code fence is the one exception that’s intentionally preserved verbatim so the client-side renderer can pick it up.

How it’s routed

frem.sh/<org>/<repo>/wiki goes through Bunny CDN. An edge rule splits on the ff_forgejo_session cookie:

• No cookie → anonymous: routed to api, which renders the public mirror (or proxies to Forgejo if not opted in).
• Cookie present → signed in: routed to Forgejo directly, which renders the native wiki with the edit affordance.

This is why search engines (which never send the cookie) crawl the public render, while collaborators always land in the editable Forgejo view.

Limits

Related

• Audit log — tenant.public_docs.toggle and tenant.public_docs.custom_css_updated actions track every change.
• Authentication policy — public docs is independent of auth-policy. Public visibility is a per-repo opt-in even on orgs with strict IP allowlists. (The mirror does not enforce IP allowlist; it’s intended to be publicly readable.)