MkDocs Material; Trilium; Wiki.js
We’ve got a seekrit project brewing at work that will eventually involve curating, publishing, and regularly updating a more-than-a-blog-but-less-than-a-full-on-“book”-book. As the madman who came up with this idea, it falls on me to poke at the least painful workflow for the team as well as the least insecure/complex stack to present to the internet.
I detest wikis and systems such as Obsidian or Notion, and not being able to use stacks that include PHP and similar terribly insecure components has had the side effect of narrowing the field down quite a bit.
While no choice has been selected (yet), I’ve narrowed the selection down to three, which we’ll briefly go over today. Please note that all “pros” and “cons” reflect our use case/biases i…
MkDocs Material; Trilium; Wiki.js
We’ve got a seekrit project brewing at work that will eventually involve curating, publishing, and regularly updating a more-than-a-blog-but-less-than-a-full-on-“book”-book. As the madman who came up with this idea, it falls on me to poke at the least painful workflow for the team as well as the least insecure/complex stack to present to the internet.
I detest wikis and systems such as Obsidian or Notion, and not being able to use stacks that include PHP and similar terribly insecure components has had the side effect of narrowing the field down quite a bit.
While no choice has been selected (yet), I’ve narrowed the selection down to three, which we’ll briefly go over today. Please note that all “pros” and “cons” reflect our use case/biases in mind. And, each section is a lightly edited extract from the notes I’ve been taking along the way.
TL;DR
(This is an LLM/GPT-generated summary of today’s Drop. This week, I continue to play with Ollama’s “cloud” models for fun and for $WORK (free tier, so far), and gave gpt-oss:120b-cloud a go with the Zed task. Even with shunting context to the cloud and back, the response was almost instantaneous. They claim not to keep logs, context, or answers, but I need to dig into that a bit more.)
- MkDocs Material offers a simple, Git‑based workflow to create mobile‑friendly, searchable static sites with versioning and optional blog support (https://squidfung.github.io/mkdocs-material/)
- Trilium Notes provides a hierarchical, SQLite‑backed personal knowledge base with full API access and powerful linking, suited for large private collections but requiring a live server (https://triliumnotes.org/)
- Wiki.js delivers a collaborative, Node‑based wiki with granular permissions, Git integration, and optional Elasticsearch scaling, though it lacks static export and needs continuous hosting (https://js.wiki/)
MkDocs Material
MkDocs Material (GH) feels immediately practical. You write plain Markdown, commit to Git, and get a professional-looking site out of it. It has a deep respect for simplicity: no databases, no runtime dependencies, no JavaScript build pipeline nonsense. Yet it doesn’t look or feel “static” in the 1990s sense. Search works offline, pages are mobile-friendly, and the theming is consistent with modern Material Design sensibilities.
It’s opinionated but flexible. You get a spiffy baseline aesthetic with plenty of hooks for customizing typography, spacing, or branding later on. The markdown extensions and syntax highlighting are excellent. Code blocks, callouts, and diagrams all look clean. This makes it a good fit for publishing network data analyses, results of queries, or quick technical notes without wrestling with front-end markup.
Client-side search seems to be fast and reliable on the real world sites I visited, and the framework does not, itself, “phone home”. It even indexes code blocks. For research/technical publications that might go offline or be mirrored, this matters.
Recent versions added a blog plugin that is surprisingly capable. It supports multiple authors, tags, and archives, which makes it possible to interleave shorter “update” posts with longer static pages documenting methodology or historical data.
The mike plugin deserves special mention. It enables versioned documentation (think “2024 Edition,” “2025 Edition”) with automatic UI for switching between them — something most static site generators handle poorly.
Speaking of which, this framework builds static pages only. Anything live — dashboards, database-backed lookups, or query results — hav to be embedded from elsewhere. You can’t turn it into a real-time app without some duct tape and bailing wire.
Every content change requires a rebuild, so performance seems to start to degrade when you cross into the thousands of pages. Previewing locally (mkdocs serve) slows down noticeably, and build times stretch. Fine for a few hundred entries, less ideal for tens of thousands of entries. (That may be a deal breaker for our use case.)
Trilium
Trilium Notes (GH) is a dense, open-source personal knowledge management system that tries to be both a personal wiki and a programmable research environment. It has a different flavor/texture from static site generators like the aforementioned MkDocs Material. It’s not so much a publisher as it is a thinking tool, built to hold sprawling webs of interlinked notes, scripts, and files.
It feels like a “backstage workshop”. It’s bonkers capable (though prone to clutter), endlessly customizable, and seems to be just a wee bit dangerous if you start pulling at the wrong threads. It’s also unapologetically deep. The interface opens onto a hierarchical tree that can go as many levels down as you’re willing to organize, clone, and cross-link. It has a very “database front-end” feel (that I do pefer over the “ugh” of Obsidian/Notion).
Everything in Trilium is a “note,” (e.g., text, diagrams, maps, mind maps, kanban boards, even embedded scripts) but that’s a super broad term. You can decorate each with attributes and relationships, then query or visualize those links as semantic maps. The core concepts are “attributes” and “relations”, so ultimately it becomes a living graph of the research contained within.
The full JavaScript API and REST interface (ETAPI b/c we totally need more acronyms) turn Trilium into more than a note app. You can ingest data, automate tagging, or even schedule analysis scripts. It’s entirely possible to pipe data in on some frequency, build relationship graphs, and generate summary reports automatically.
The backend is built on SQLite backend and can handle yuge datasets gracefully — tens or even hundreds of thousands of notes. Most wikis crumble under that kind of scale.
You can sketch network topologies on canvas notes, build timelines with Mermaid, or paste logs into code blocks with syntax highlighting (I may be giving too much of the seekrit project away). Everything lives in one cohesive structure, cross-referenced and searchable.
This project sounds great for the collection side of what’s planned, but the sharing feature is meant for peer collaboration, not public presentation. You can technically publish notes as web pages, but they look barebones, lack SEO, and don’t scale to high traffic. Unlike MkDocs, Trilium serves content live from said SQL database. That means continuous hosting, a server to maintain, and none of the advantages of static site delivery (speed, cacheability, CDN friendliness).
Another downside is that the “app” is (ugh) Electron. As such, folks report that it can feel sluggish on large vaults, and setting up secure sync or sharing involves real sysadmin work — certificates, TLS, and caution. It’s not “double-click and go.”
I’ve seen a few fledgling projects that use this as a backend and then have some front-end generators pull content from it. But, we could do that with Obsidian (which the team is already familiar with). Still, it’s on the list as it seems better suited for at least the collection and organization components of the project.
Wiki.js
Wiki.js (GH) sits at an interesting midpoint between a lightweight static generator and a full-blown knowledge system. It has a super modern feel, and is an “app” (vs static site), built on Node.js with a clean interface and broad authentication (LDAP, SAML, OAuth, or Okta) support. Confluence wishes it could be Wiki.js when it grows up.
Where MkDocs expects you to think like a developer, Wiki.js invites you to think like an editor or knowledge architect. It’s designed for collaboration, supporting multiple users, different editing modes, and structured permissions.
Unlike Trilium or other internal-first tools, Wiki.js is purpose-built for outward-facing knowledge bases. It produces a spiffy, professional front end that looks like it belongs to a serious organization.
It does rely on (ugh) GraphQL, which almost caused me to close the tabs I had open for it. But, enough other features were useful that we might be able to live with this serious flaw (or work around it).
Granular access control means the team can easily separate public and internal content. That means we can keep speculative, “in progress” notes part of a topic but separate from published knowledge. Git integration ensures everything’s backed up, diffable, and versioned. Pair that with PostgreSQL (the recommended backend), and you’ve got solid data integrity and auditability as well.
Search works out of the box and can scale to (ugh) Elasticsearch if needed. Built-in diagramming (UML, Mermaid) makes it easy to render all the flows/diagrams we’d need without external tools.
So, weirdly enough, Wiki.js cannot run from a subfolder, but that’s fine since we planned on using a new subdmain. But, for Drop readers, please relize that this is a non-negotiable requirement.
There’s also no static export option — the wiki must run as a live Node.js app. That means server maintenance, resource monitoring, and a heavier operational footprint than MkDocs. No free CDN or static hosting shortcuts here.
It’s also a bit concerning that the long-promised Wiki.js v3 has been in development limbo since 2022. The current v2.x branch is stable, but the future trajectory feels slower and more community-driven now. It’s not abandonware, but it’s also not evolving rapidly.
Performance is reportedly fine for a few thousand pages but can falter beyond that. And while multiple users can edit collaboratively, there’s no real-time simultaneous editing — it’s strictly one-at-a-time save-based workflow.
Wiki.js seems to be much closer to being suitable for our needs than Trilium would be, but gosh I don’t think any of us really wants to run yet-another app server.
FIN
Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:
- 🐘 Mastodon via
@dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev - 🦋 Bluesky via
https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy
☮️