Every operator accumulates a knowledge base whether they plan for one or not. Glossary entries. Runbooks. The exact cloudflared flag that fixed the thing at 2am. The reason you stopped paying for a service. Most people scatter this across Notion, a Notes app, three Slack channels, and their own memory. Then the SaaS jacks the price, deprecates the export, or quietly trains on your private pages.
A wiki is the most boring, most durable piece of a sovereign stack, and almost nobody self-hosts it. They should. It is mostly static text. It does not need a GPU. It does not need a vendor. And once it runs on hardware you own, it becomes the index your local models read from instead of phoning home.
This is how to build one on the same one-Mac-three-domains pattern that already serves my production sites, and how to wire a local MLX model into it so search actually understands what you wrote.
Why a Wiki Is the Easiest Thing You'll Ever Self-Host
A wiki has the gentlest resource profile of anything in the stack. The corpus is text. Rendering is cacheable. There are no fan messages flooding in, no audio masters churning the disk, no model weights pinned in memory. If your Mac can serve a Next.js marketing site, it can serve ten thousand wiki pages without noticing.
The trap people fall into is reaching for a heavyweight wiki engine — Confluence, MediaWiki, a Postgres-backed monster with a plugin marketplace. You do not need any of that. You need files on disk and a renderer. Markdown or MDX in a content/ directory, version-controlled in git, rendered by the static-site framework you already run. That's it. The "database" is the filesystem, and the filesystem is already backed up.
This is the same logic behind running production sites off one machine: the simplest architecture that survives a reboot is the one you'll still trust in a year.
The Stack: Files, Next.js, One Tunnel
Here's the shape of it, concretely.
Content layer. A flat directory of .mdx files, one per page, with YAML frontmatter for title, tags, and category. Frontmatter is your taxonomy — it's how you turn a pile of notes into a navigable glossary without a database schema. Glossary terms get a type: term tag; runbooks get type: runbook. You query by reading the frontmatter at build time.
Render layer. Next.js reads the directory server-side, builds an index, and renders each page. Internal [[wikilinks]] resolve to routes by slug. A category page is just a filtered list of frontmatter. You're writing maybe 200 lines of glue, not standing up a platform.
Serve layer. The Next.js process listens on a local port under launchd so it restarts on crash and on boot. No PM2, no Docker, no orchestration. One process, one port.
Edge layer. A single Cloudflare named tunnel maps wiki.yourdomain.com to that local port. The tunnel is bound to credentials, not to an IP, so there's no port-forwarding, no exposed home address, no static-IP requirement from your ISP. The same config.yml that host-routes your other domains gets one more ingress rule. If you already run the tunnel pattern, adding a wiki is four lines of YAML and a cloudflared restart.
That's the whole production path. The Mac does the work, Cloudflare does the TLS and the edge, and you own every byte in between.
Make It Private — Or Don't
Decide early whether this wiki is public reference or internal ops. Both are valid; they need different front doors.
A public glossary — terms, definitions, explainer pages — wants to be indexed and fast. Serve it openly, let Cloudflare cache it, let search engines crawl it. This is the cheapest evergreen content you'll ever publish, because you were going to write the notes anyway.
An internal runbook wiki should never be indexed. Put Cloudflare Access in front of it — a one-time-PIN email policy or a service token takes ten minutes to configure on the tunnel and gates the whole hostname before a request ever reaches your Mac. Add X-Robots-Tag: noindex for belt-and-suspenders. Now your 2am fixes live on the public internet's plumbing but behind your own lock.
The point of sovereignty isn't "everything is private." It's that you draw the line, per-hostname, and no vendor moves it on you.
Wire In a Local Model and Search Stops Being Dumb
Keyword search on a wiki is fine until the day you search "tunnel won't start" and the page that solves it is titled "ingress rule ordering." Keyword search doesn't know those are the same thing. A local embedding model does.
This is where the sovereign AI stack earns its keep. Run a small embedding model with MLX on Apple Silicon — a sentence-transformer-class model serves a few hundred chunks per second on an M-series chip and costs nothing per call. At build time, chunk every wiki page, embed it, and write the vectors to a local SQLite file alongside your content. At query time, embed the search string and do cosine similarity in-process. Semantic search, fully local, no API, no rate limit, no data leaving the machine.
Then go one step further: point a local vision-or-text model like Qwen2.5-VL through LM Studio at your own corpus. Retrieve the top-k chunks by embedding similarity, stuff them into the prompt, and you have retrieval-augmented answers grounded in your runbooks instead of the model's training data. Ask "how do I recover after the Mac dies" and it answers from your actual recovery doc, citing the page. The model becomes a librarian for the knowledge you already wrote down — and it does it on hardware sitting on your desk, on a corpus a cloud provider never sees.
This is the whole sovereign thesis in one feature: the same machine that holds your knowledge also reasons over it, and the loop never touches anyone's metered API.
What It Costs and What It Saves
The marginal cost of this wiki is zero. The Mac is already running. The tunnel is already up. Cloudflare's free tier covers the edge. The embedding model is a one-time download. You are not adding a line item; you are deleting one — the Notion-team seat or the hosted-wiki subscription you were about to renew.
The real saving is structural. Your knowledge stops being a hostage. There's no export-button anxiety, no "we're sunsetting this plan" email, no price increase you can't refuse because all your runbooks are inside. The content is plain text in git. If your Mac dies, you restore from Time Machine, repoint the tunnel to the new machine, and you're live in hours — the tunnel follows the credentials, not the hardware.
Boring, owned, and durable beats slick and rented. That's the entire pattern.
FAQ
Do I need a vector database for the search?
No. For a personal or team wiki — even tens of thousands of chunks — a single SQLite file holding your embeddings and a brute-force cosine scan in-process is plenty fast on Apple Silicon. Reach for a dedicated vector store only when you're past hundreds of thousands of vectors, which a wiki almost never is.
Can I edit the wiki without touching the terminal?
Yes. Because pages are just .mdx files in a git repo, you can edit them in any Markdown app, on GitHub's web editor, or with a local CMS that writes to the same directory. The render layer picks up changes on the next build or via file-watching in dev mode. No proprietary editor required.
Why MLX instead of running embeddings in the cloud?
MLX is built for Apple Silicon's unified memory, so a small embedding model runs locally at a few hundred chunks per second with no per-call cost and nothing leaving the machine. The whole reason to self-host a knowledge base is that your private notes stay private — sending them to a cloud embedding API would defeat the purpose.
How is this different from just keeping a Notes folder?
A folder gives you files; a wiki gives you structure and recall. Frontmatter turns notes into a queryable taxonomy, wikilinks turn them into a graph, and local embeddings turn them into something a model can actually answer from. You get the durability of plain files plus the navigation and search you'd otherwise rent from SaaS.