C Systems Lab Wiki

Wiki Hosting — Implemented

7 min read

Wiki Hosting — Implemented

Status: LIVE — llc-wiki.pages.dev (Quartz 4 + Cloudflare Pages)
Auto-deploys on push to VHCosta/llc-wiki. PWA-enabled with {c} B&W favicon.

The plan below is preserved for reference. The chosen option (Quartz + Cloudflare Pages) was implemented on 2026-04-11.

Goal: serve the wiki as a website accessible from anywhere, with enough privacy that internal strategy docs (pricing, product decisions, open questions) are not indexed publicly.

Project-specific constraints

Before evaluating options, what this wiki actually is:

  • Obsidian-compatible Markdown — uses [[wikilinks]], frontmatter, flat tag set
  • ~45 pages across modules/, concepts/, sources/, meta/
  • Maintained by Claude Code — new pages and updates pushed to GitHub via git
  • Internal use — product strategy, pricing, open questions, build decisions; not meant for public indexing
  • No interactive features needed — read-only reference, fast search, good navigation

Options

Option 1 — GitHub Pages (native)

GitHub’s built-in static site host. Enable in repo settings, point at the wiki/ folder, optionally add a Jekyll theme.

Pros: Zero config, already on GitHub, free
Cons:

  • [[wikilinks]] are not natively supported — they render as plain text, not links
  • Public by default; private Pages requires GitHub Pro/Enterprise (~$4/mo per user)
  • Jekyll themes are dated; no backlink graph or fast client-side search
  • Maintenance: every page would need standard markdown links to work properly

Verdict: Only viable if the wiki is refactored to use standard links. Not worth it when better options exist.

Option 2 — Quartz + Vercel ← Recommended

Quartz is a static site generator built specifically for Obsidian-style vaults. It understands [[wikilinks]], renders backlink graphs, and generates fast, searchable sites. Vercel hosts the output for free.

How it works:

  1. Add Quartz to the wiki repo (it ships as an npm package / git submodule)
  2. Add a quartz.config.ts pointing at the wiki/ content folder
  3. Push to GitHub — a GitHub Action (provided by Quartz) builds and deploys to Vercel on every push
  4. The site is live at <project>.vercel.app or a custom domain

Pros:

  • Native [[wikilink]] support — zero refactoring of existing pages
  • Backlink graph (the “digital garden” view), tag pages, full-text search
  • Vercel free tier is generous; no cost for a wiki this size
  • Custom domain support (e.g. wiki.csystemslab.com or just a private Vercel URL)
  • Password protection via Vercel’s Deployment Protection (free on Pro plan, ~$20/mo) or via a simple middleware function
  • Automatic deploy on git push — Claude Code’s workflow already writes and pushes, so the site stays live with no extra steps

Cons:

  • Initial setup is ~30–60 minutes (Quartz install, config, Vercel project link)
  • Vercel free tier does not include password protection — needs Vercel Pro or a workaround (see Privacy section below)
  • The backlink graph requires [[wikilinks]] to be consistent — orphan pages with no inbound links won’t appear in it

Verdict: Best fit. Designed for exactly this use case.

Option 3 — MkDocs Material + GitHub Actions

MkDocs with the Material theme is the industry standard for technical documentation. A GitHub Action builds and deploys on push.

Pros:

  • Excellent code block rendering, built-in search, LaTeX math support
  • GitHub Actions deployment is free
  • Clean, professional look familiar to developers

Cons:

  • [[wikilinks]] are not supported — would require a plugin (mkdocs-autorefs partially covers this) or refactoring all links to standard Markdown
  • No backlink graph
  • Nav structure must be maintained manually in mkdocs.yml; the wiki’s current structure is self-organizing via wikilinks

Verdict: Better for a docs site with a fixed structure. Worse for an evolving knowledge base with cross-links.

Option 4 — Obsidian Publish

Obsidian’s official hosted publishing service. $10/month. Point-and-click.

Pros: Zero config; exactly matches Obsidian’s feature set
Cons: $10/month for a single vault is expensive for internal tooling; the wiki is maintained by Claude Code, not via the Obsidian app, so the tight Obsidian integration is not a benefit

Verdict: Overpriced for this use case.

Option 5 — Cloudflare Pages (alternative to Vercel)

Same idea as Quartz + Vercel, but hosted on Cloudflare Pages instead. The project already uses Cloudflare Pages for the web app.

Pros: Consistent with existing infrastructure; Cloudflare Access provides free SSO-based access control (can gate by email address with zero-trust rules)
Cons: Quartz’s first-party GitHub Action targets Vercel; would need a custom build step for Cloudflare Pages

Verdict: Worth considering if using Cloudflare Access for access control is important — that’s a strong privacy option. Slightly more setup than Vercel.

Comparison

OptionWikilinksPrivacyEffortCost
GitHub Pages✗ (broken)Public / paidLowFree / $4mo
Quartz + Vercel✓ nativeWorkaround / Vercel ProMediumFree / $20mo
MkDocs + GH Actions✗ (plugin needed)Public by defaultMediumFree
Obsidian Publish✓ nativeCustom domainVery low$10mo
Quartz + Cloudflare✓ nativeCloudflare Access (free SSO)Medium+Free

Recommendation: Quartz + Vercel (or Cloudflare Pages)

Quartz is the only option that handles the wiki’s existing [[wikilinks]] structure without refactoring. The automatic Vercel deploy fits the existing Claude Code workflow — push to GitHub, site updates.

If privacy is the priority: Use Quartz + Cloudflare Pages + Cloudflare Access. Access allows you to gate the site by your Google/GitHub login — no password to manage, no paid plan required, and it’s the same Cloudflare account already used for the web app.

If simplicity is the priority: Quartz + Vercel free tier with an obscure Vercel URL (not linked from anywhere public, not submitted to search engines). Add a robots.txt that disallows crawlers. This is “security by obscurity” — adequate for personal internal docs that aren’t sensitive secrets.

Implementation plan (Quartz + Cloudflare Pages)

Step 1 — Scaffold Quartz in the wiki repo

cd /home/llc-course/wiki
npx quartz create          # installs Quartz, creates quartz.config.ts

Point Quartz at the wiki/ content folder in quartz.config.ts:

configuration: {
  pageTitle: "C Systems Lab Wiki",
  contentFolder: "wiki",   // relative to repo root
}

Step 2 — Verify locally

npx quartz build --serve   # opens localhost:8080

Check that [[wikilinks]] resolve, frontmatter renders, and search works.

Step 3 — Deploy to Cloudflare Pages

  1. In Cloudflare Dashboard → Pages → Create application → Connect to Git
  2. Select VHCosta/llc-wiki
  3. Build command: npx quartz build
  4. Build output directory: public
  5. Deploy

After first deploy, Cloudflare assigns a *.pages.dev URL.

Step 4 — Add Cloudflare Access (optional but recommended)

  1. In Cloudflare Zero Trust → Access → Applications → Add
  2. Select the *.pages.dev URL (or custom domain)
  3. Add a policy: allow your email address (or a GitHub OAuth login)
  4. Anyone who hits the URL without being authenticated gets a login prompt

This is free on Cloudflare’s personal plan.

Step 5 — Custom domain (optional)

Point wiki.csystemslab.com (or similar) at the Cloudflare Pages deployment. DNS is already managed by Cloudflare, so this is a one-click addition.

Maintenance workflow after setup

No changes to the Claude Code workflow:

  1. Claude writes and edits wiki pages
  2. Changes committed and pushed to VHCosta/llc-wiki
  3. Cloudflare Pages detects the push, rebuilds, and redeploys automatically (~30–60 seconds)
  4. Wiki is live at the configured URL

Open questions

  1. Custom domain? wiki.csystemslab.com vs. a plain *.pages.dev URL. The custom domain requires the domain to be on Cloudflare DNS (it already is for the web app, so this should be straightforward).
  2. Public vs. gated? If the wiki ever becomes a public resource (e.g., “how this course was built” as a blog-style publication), removing the Cloudflare Access gate is trivial. Build the gate first; remove it later if the decision changes.
  3. Search indexing? Even without a gate, adding robots.txt with Disallow: / prevents Google from indexing the site. This is the minimum viable privacy measure for the “security by obscurity” path.

Graph View

Backlinks