🍄 Not a feed. A body of work.
Every mainstream web framework quietly encourages the same architecture: serve a shell, fetch data on the client, assemble the page in the browser. The client-side join.
It feels modern. It is catastrophically wasteful.
The server already had the data. It could have rendered the HTML. Instead it sent a bundle, which fetched JSON, which rendered DOM, which then became the thing the server could have sent in the first place. Two round trips. Megabytes of JavaScript. A loading spinner as the default UI.
We noticed this. And then we couldn't stop noticing it.
The platform problem
I wanted to publish things on the internet — writing, projects, demos — without handing my content to a platform that would flatten it into a feed, bury it under an algorithm, and claim ownership in the ToS.
Social media reduces you to a uniform commodity: "user data." Your content exists to generate engagement metrics. The algorithm decides who sees it and when. Anything older than a few hours is effectively gone — not because it stopped being good, but because recency is what sells ads.
I wanted the opposite. A structure that grows over time. Multidimensional — mycelial, even — where nothing degrades, nothing gets buried, and everything remains mine. Not a feed. A body of work.
The vite era
We built the first version of Fungal as a set of Vite plugins. Vite was the consensus best-in-class tool, and we believed the hype.
It worked, sort of. But Vite has a dual pipeline — one for dev, one for production — and our use case didn't fit either cleanly. We were doing static site generation with a pods-based content model: each piece of content is a self-contained directory with its own metadata, markdown, assets, and optional component overrides. Vite was designed for single-page apps. We were bending it sideways.
The kludges piled up. Ordering issues. Interleaving bugs. Plugin hooks firing in the wrong sequence. Every fix introduced a new edge case. We spent more time patching Vite's assumptions than building our actual site.
And then there was the performance. JavaScript is not a fast language. Rebuilding a site with a few hundred pods took seconds where it should have taken milliseconds. The gap between what was physically possible and what we were getting felt insulting.
So we rewrote it in Go.
What Fungal actually is
Fungal is a static site generator built specifically for the pods model. No plugin hacks. No framework to fight. The conventions are the architecture.
A pod is a directory:
content/my-article/
pod.toml
doc.md
hero.png
A pod.toml, a doc.md, and whatever else that content needs. Pods compose into a site through roots and themes. That's the whole model.
What you get from that model:
Forever-caching. Every asset gets a content-addressed filename — a hash of its contents baked into the URL. If the content hasn't changed, the URL hasn't changed, and the browser serves it from cache. If it has changed, the URL is different, and the browser fetches the new version. No cache-busting headers. No version query strings. The fastest HTTP request is the one not made.
Name a greener architecture. Static HTML served from the edge. No origin server. No database. No application runtime. Thousands of requests handled with almost zero CPU. Nothing running that can crash, nothing to scale, nothing to babysit.
Perfect versioning. Drafts and revisions are git conventions. Branch for a draft, merge to publish. The same workflow battle-tested on millions of software projects, now applied to content. No CMS. No draft/published toggle. No "are you sure you want to publish?"
Intelligent bundling. Fungal uses esbuild to analyze your components and produce only the chunks needed for each page. If a pod uses a date picker, that page gets the date picker chunk. If it doesn't, it doesn't. No config. No manual code splitting. No wasted bytes. The auto-loader handles the script tags so you never think about it.
Pods can be anything. There are no restrictions. A pod can be a blog post that fully participates in the theme. It can be a landing page that overrides every template. It can be an interactive demo with its own components and styles. Each pod decides how much of the theme it wants, from everything to nothing. Design-system compliance with zero effort when you want it, full creative control when you need it.
Cloudflare-native. You don't have to use Cloudflare, but if you do: add a wrangler.toml, push, and you're live. Thirty-second builds. Global edge delivery. Custom domains. No ops.
The mycelium metaphor
Fungal is named after fungi because the architecture mirrors how mycelial networks work.
A mushroom is the visible fruiting body, but the organism is the mycelium — a vast underground network that connects, decomposes, and redistributes. It doesn't have a center. It doesn't degrade. Old parts of the network don't become irrelevant because new parts grew.
That's what a personal site should be. Not a feed where today's post buries yesterday's. A growing structure where everything remains connected, discoverable, alive. The oldest page is as accessible as the newest. The structure gets richer over time instead of collapsing under its own weight.
Platforms want your content to be ephemeral because ephemeral content drives engagement. Fungal wants your content to be permanent because it's yours.
Install
curl -sSf https://releases.fungal.party/install.sh | sh
No npm. No node. No GitHub account required. One binary, built in Go, does everything.