DEV Community: perber

Fourteen months of LeafWiki, in small moments

perber — Thu, 16 Jul 2026 09:00:00 +0000

LeafWiki has 802 stars on GitHub right now. By the time you read this, that number is already wrong.

Fourteen months since the first release. Not a round number, but that's the actual gap, so I'm using it. If you pull up the star history, it looks like a hockey stick — flat for most of a year, then a near-vertical line at the end. That's not how it felt while it was happening. It felt like a handful of separate moments, months apart, that only add up to a curve if you squint at it after the fact. Here's what actually happened, in order.

A quiet release nobody noticed

v0.1.0 went live on April 30, 2025. No launch post, no announcement. The commit that shipped it still says "LeafWiki is alive" — I kept the old releases folder around just because that line is in there.

I built it for myself. A friend and I had complained about Wiki.js over a beer — I wrote about that part separately. This is about what came after the beer.

Nothing happened for a while. That was fine. I hadn't built it for anyone else yet.

The issue that came after a long summer

Months went by. Then, after a quiet summer with barely any activity, someone filed an issue.

That's it. That's the whole milestone. One issue, from someone I didn't know, on a project I'd half-forgotten to keep pushing on.

It's a strange thing to admit, but that single issue is what got me building faster again. Not a star count, not a mention anywhere — one person taking the project seriously enough to report a bug.

Someone who said he'd help, then went quiet

The project was sitting at around 50 stars — nothing much — when I labeled a few issues "good first issue," hoping someone would pick one up. Someone did. He commented that he'd take it on.

Then nothing. No pull request, no update, no message saying he'd changed his mind. He just never came back.

No hard feelings — that's just how a lot of open source goes. People show up for exactly as long as they meant to, and they don't owe you an explanation for leaving. I don't think about it as a loss.

A pull request I almost missed

Later, someone else opened a PR without asking first — no issue, no discussion, just a change. Then he closed it himself, before I'd even seen it.

I found it later, reopened it, and pinged him to say the idea behind it was good. If I hadn't noticed, he'd probably have been gone for good.

That person has stuck around and supported the project ever since. I'm keeping the details vague here by their preference, but it's one of the clearest examples I have of something I didn't expect going into this: the people who end up caring most aren't always the ones who show up loudest first.

Sergio, and the first person who kept paying

The first recurring sponsor showed up a while after that — Sergio, who'd been filing issues and testing versions for months already. That story is its own post, so I won't retell it here. Short version: he started paying every month without saying a word first, and I still think about that.

Posting it, for the first time

I don't spend much time on social media. Writing the code never scared me. Posting it anywhere outside GitHub did.

I put up a Hacker News submission for the "ops team" post — just a link to the blog, nothing more.

Self-hosted wikis shouldn't need an ops team — 10 points, 2 comments. Not a viral moment by HN standards.

A few days after that post, someone I'd never interacted with before sponsored the project — a single, one-time payment, not a recurring one. Not Sergio, someone else entirely. The first time anyone had paid anything for LeafWiki without it turning into an ongoing thing.

Then, a few days after that, came the post that actually moved the star count.

The post that actually moved the number

I'd already written a few dev.to posts and picked up a small, steady trickle of users from those. Posting about the v0.10.0 release on r/selfhosted felt exactly as uncomfortable as the Hacker News post had — same nerves, different platform.

72 stars in one day. Then 64 the day after. That's still the single largest jump in the entire history of the project — bigger than every press mention combined. One honest post about a release did more than months of quiet building.

Two mentions I didn't ask for

Self-Hosted Weekly mentioned LeafWiki once as a regular app listing, then featured it in their spotlight section a week later. Go Weekly picked it up not long after — that one landed differently. No single-day spike; the stars came in steadily over the following day instead, closer to how people actually read a newsletter than how they scroll a feed.

I didn't pitch either one. Someone just noticed and wrote about it.

Where that leaves things

802 stars. A handful of sponsors. One person who filed an issue after a long silence and got me building again. One contributor who came and went. One who stayed. Still one person — me — writing the code, on evenings and weekends, next to actual client work.

What's actually changed is the room around it. Most feature requests now come from people using LeafWiki for things I never anticipated. Some just tell me what's missing. A few build it themselves and open a PR instead of a wishlist. Discussions that used to sit unanswered for weeks now get real back-and-forth, sometimes before I've even seen them myself.

If you're building something in public and it doesn't feel like it's compounding — it probably isn't, not smoothly. Mine didn't. It moved in steps, and most of the steps were just one person doing one small thing at exactly the right moment. You only see the line if you draw it backward.

LeafWiki is still free, still open source, still on GitHub if you want to look at where all of this actually lives.

I built a boring wiki on purpose

perber — Tue, 30 Jun 2026 14:03:23 +0000

Boring is a compliment.

I started LeafWiki alone, about a year ago. Single Go binary, SQLite, Markdown on disk. No Redis, no Node.js, no Postgres.

Most people building wiki tools today are trying to build the next Notion. Or Confluence. Or Obsidian. I understand the instinct — those tools are successful, and closing the feature gap feels like progress.

I went the other way.

Three categories I decided not to compete in

Everyone seems to be building a Confluence clone — team wikis with approval workflows, granular permissions, nested spaces, and enterprise SSO. For a team of five writing runbooks, that's a lot of surface area to operate.

Everyone seems to be building a Notion clone — databases, Kanban boards, real-time collaboration, AI summaries. Notion is genuinely impressive. It's also become everything. People build workarounds inside it for things it was never designed to do. The tool becomes infrastructure. And then the tool needs its own ops team.

Everyone seems to be building an Obsidian clone — local-first, graph view, personal knowledge management. I like Obsidian. It's a great tool. But it's a personal tool. The moment a second person needs to write something, the model breaks.

LeafWiki is none of these. It's a team wiki. That's a smaller, more boring problem. That's the point.

The decision that shaped everything

Markdown files on disk are the source of truth. Not the database.

The database is a cache. On restart, the system reads everything back from the Markdown files. If the database is gone, the content isn't. Backup means cp -r.

One exception: user accounts live in users.db and need to be included in your backup. Content is in the files; credentials aren't.

That sounds simple. It isn't.

Revision history. Link refactoring when pages are renamed. Keeping in-memory state and files consistent across concurrent writes. In a Postgres-backed tool, these are straightforward. When the files are what matters, you do the work properly or you corrupt content.

The easy path is Postgres. I didn't take it. I wanted content that survives without the application — readable in a text editor even if the server is gone.

The other thing nobody talks about: atomic writes.

When a user saves a page, two things need to happen: the Markdown file on disk has to be updated, and the in-memory SQLite cache has to reflect the change. You can't wrap both in a database transaction — one of them is a file.

The approach: write to a temp file first, then os.Rename(). On Linux, rename is atomic at the filesystem level — readers either see the old file or the new one, never a half-written state. The SQLite update follows after the rename.

If the process crashes between the rename and the SQLite update, the cache and the files drift. That's intentional. On restart, the system reads from files and rebuilds the cache. Files win. That's the contract.

This forces a discipline: nothing important can live only in SQLite. Any feature that stores data only in the cache loses that data on restart. The architecture makes you honest about what the source of truth actually is.

Two more decisions that follow from this:

Page metadata — IDs, revision references, internal assignments — lives in the frontmatter of each Markdown file. Not in the database. That way a full reconstruct on restart reads everything it needs directly from the files, with no dependency on cached state that might be stale or missing.

Page ordering within a section is stored in a .order.json sidecar file alongside the Markdown files. Filesystems don't guarantee consistent ordering across platforms, so you need somewhere to persist it. A tiny JSON file next to the content is the simplest answer that survives a restart, a migration, or a manual cp -r to a new server.

What I said no to

Outline uses Redis for real-time collaboration. In practice, most small teams rarely need two people editing the same page simultaneously — they assumed they did because Notion has it.

No Redis. No real-time collaboration. No AI features in the UI. No PDF export pipeline that requires Node.js. One binary, no external dependencies.

Every one of these was a reasonable request. Each one would have pulled the project toward something heavier — something that needs its own maintenance schedule, something that eventually becomes the problem instead of the solution.

What I cared about instead

I like Obsidian's editor. I wanted that feeling — sitting down and writing without the interface getting in the way.

Most wikis feel like websites. Click a link, the page reloads, the sidebar resets. Wiki.js had a specific problem I couldn't ignore: a 404 made the entire navigation tree disappear. A broken link shouldn't break the interface.

LeafWiki is a SPA. Navigate between pages and nothing reloads. The Go binary delivers Markdown content fast. CSS and JavaScript load once. The frontend is compiled into the binary at build time via Go's embed — no static file server, no asset directory to manage.

The SQLite library is pure Go (modernc.org/sqlite) — no C compiler needed. That's part of why the binary is genuinely self-contained. Download it, run it.

Ctrl+Alt+P finds a page by title. Ctrl+V pastes an image. Creating a new page takes seconds.

DokuWiki understood something twenty years ago: files are enough. No database required. The interface just didn't keep up. I wanted what DokuWiki understood, with an editor you actually want to write in.

Whether it was the right call

About a month ago I noticed the first sponsor on GitHub. Someone from the community — filing issues, testing versions, shaping features since early on. The custom favicon support came from him. Sections in the navigation tree came from him.

He'd switched from Wiki.js. He's building a hardware documentation wiki — parts, assemblies, technical guides for a real project. His description:

"here it's just 'create page in sidebar → upload assets per page → done'"

He quietly started paying — without being asked, without a pricing page.

That felt like the right answer to the question.

Pre-1.0, actively developed, free and open source: github.com/perber/leafwiki

Live demo at demo.leafwiki.com — resets every hour.

v1 is focused on making LeafWiki company-ready — two-factor authentication, email and user invitations, and Git sync are coming.

If you like the direction: a GitHub star helps others find it. And if you want to support development directly, GitHub Sponsors is the most direct way.

LeafWiki Devlog #10: v0.9.0 – no more broken links, lost edits, or overwritten changes

perber — Sat, 02 May 2026 18:23:45 +0000

LeafWiki - A self-hosted wiki for long-lived documentation.
Built for engineers, self-hosters, and small teams.

LeafWiki v0.9.0 is out. This release focuses on four problems that come up in any shared wiki over time.

"Someone changed something last week — what did it look like before?"

The revision system stores Markdown snapshots for every page save. You can browse the history, read older versions, and restore any of them.

Assets are deduplicated across revisions, so history does not balloon your storage.

Enable it with --enable-revision. The default history limit is 100 revisions per page, configurable with --max-revision-history.

"I moved a section and now half the links are broken"

Link refactoring tracks internal links across the wiki. When you rename or move a page, LeafWiki shows you every page with an affected link and lets you decide whether to update them — before anything breaks.

Enable it with --enable-link-refactor=true.

"Two of us edited the same page and one overwrote the other"

LeafWiki now uses optimistic locking. If your version of a page is out of date when you try to save, you get notified before anything is written. You can review what changed and decide whether to overwrite or merge manually.

No more last-write-wins.

"I shared this link and now it's dead because we restructured"

Pages now have permalinks — short, stable URLs that resolve to the correct page even after it has been moved or renamed. Safe to share in Slack, emails, or external docs.

Shoutout boxes

Callout blocks have been extended. Predefined types (:::info, :::warning, :::error) and color-based variants (:::blue, :::red, :::green) are available, as well as custom shoutouts without titles for more flexible styling.

Importer improvements

The importer now resolves WikiLinks and Markdown links between pages, connects relationships, and handles asset uploads more reliably.

Thanks to everyone who provided feedback and tested early versions!

Try the demo, Visit the Project Website or grab the latest release on GitHub.

LeafWiki Devlog #9: v0.8.2 – Tree Improvements & Reverse Proxy Support

perber — Sun, 08 Mar 2026 18:27:16 +0000

Hi!

Time for another small update on LeafWiki.

Version v0.8.2 focuses on usability improvements in the Tree View and a small but very useful deployment feature for self-hosted setups.

If you're new here:

LeafWiki is a lightweight, self-hosted Markdown wiki built as a single Go binary.

Markdown files stored directly on disk
No external database service required
Designed for people who think in folders, not feeds

If LeafWiki disappears tomorrow, your content is still yours.

GitHub: https://github.com/perber/leafwiki

A quick recap: the 0.8 series

With v0.8.0, LeafWiki introduced one of the biggest structural changes so far: Sections.

Sections allow the wiki tree to behave more like a real folder structure.

Instead of every node being a page, a node can now simply act as a container for other pages.

This enables things like:

cleaner hierarchical structures
better organization for larger documentation sets

v0.8 also introduced import and recovery tools, making it much easier to bring existing documentation into LeafWiki or rebuild the wiki structure from files on disk.

With that structural foundation in place, the following releases in the 0.8.x series focus on refinement — improving usability, performance, and deployment flexibility.

Reverse Proxy Support (`--base-path`)

One improvement in v0.8.2 makes LeafWiki easier to run behind reverse proxies.

LeafWiki now supports a --base-path flag, which allows the application to be served from a subpath instead of the domain root.

This enables setups like:

https://example.com/wiki

instead of requiring:

https://wiki.example.com

Why this matters:

Many self-hosted environments run multiple services behind a single domain using tools like:

Nginx
Traefik
Caddy
corporate reverse proxies

Supporting a base path makes LeafWiki much easier to integrate into these environments without requiring a dedicated subdomain.

For self-hosters, this makes deployments a lot more flexible.

Tree View usability improvements

As wikis grow, navigation becomes increasingly important.

v0.8.2 adds Expand All and Collapse All actions to the Tree View.

This makes it much easier to quickly:

explore the full structure of a wiki
collapse everything to focus on a specific section
navigate large documentation trees

It’s a small feature, but it becomes very useful once a wiki contains many nested pages and sections.

What’s next

With the structural work introduced in v0.8.0, the current focus is on polishing the experience around the new tree model.

The goal is to keep LeafWiki simple, fast, and predictable — while gradually improving the everyday experience of using it.

Thanks to everyone who reports issues, suggests improvements, or contributes to the project.

Your feedback continues to shape the direction of LeafWiki 🌿

If you'd like to try it out or follow development:

https://github.com/perber/leafwiki

LeafWiki Devlog #8: v0.7.3 - Secure by Default: Authentication, Roles & Safer Self-Hosting

perber — Sun, 01 Feb 2026 12:59:52 +0000

Hi,

This release marks an important step for LeafWiki.

With recent versions, LeafWiki has moved beyond a purely personal wiki running on localhost.
People are now running it on servers, exposing it to internal networks — and sometimes to the public internet.

That shift comes with new responsibilities.

So v0.7.x focuses on something less flashy than backlinks or editors — but far more important in the long run:

Security, authentication, and safer defaults for self-hosted setups.

A quick reminder: what LeafWiki is

If you're new here:

LeafWiki is a lightweight, self-hosted Markdown wiki built as a single Go binary.

Markdown files on disk
No external database service
Designed for people who think in folders, not feeds

If LeafWiki disappears tomorrow, your content is still yours.

GitHub: https://github.com/perber/leafwiki

Why security became a priority now

Security was always considered in LeafWiki — but v0.7.x is where it becomes intentional and explicit.

Two things triggered this:

LeafWiki started to be used for real internal documentation
Instances were being exposed beyond localhost

At that point, authentication and access control stop being nice to have and start being table stakes.

But there was one constraint I didn’t want to break:

Adding security must not turn LeafWiki into an operational project.

No extra services.

No complex setup.

No surprise defaults.

Secure by default, flexible by design

The guiding principle for this release was simple:

Secure by default — but explicit when you want to opt out.

That principle led to a few foundational changes.

Authentication & session handling

LeafWiki now uses session-based authentication backed by a local database.

What this enables

Secure, HttpOnly cookies enabled by default
CSRF protection on all state-changing requests
Rate limiting on authentication-related endpoints
Configurable access and refresh token timeouts

These are boring features — and that’s a good thing.

They are meant to quietly do their job without being noticed.

All of this works without introducing external dependencies or services.

Roles & access control

LeafWiki now supports explicit roles:

Admin
Editor
Viewer (read-only)

This makes a big difference for common setups like:

Public documentation with authenticated editing
Internal runbooks where most users only read
Small teams with a single maintainer

If authentication is disabled, editing without login is still possible — but it is now an explicit choice, not an implicit side effect.

Escape hatches (and why they exist)

Two new flags were added in v0.7.0:

--allow-insecure
--disable-auth

These are not shortcuts.

They are deliberate escape hatches.

`--allow-insecure`

Required for HTTP-only setups where Secure/HttpOnly cookies would otherwise break local development.

`--disable-auth`

Completely disables authentication and authorization.

This flag is intended only for:

Local development
Trusted internal networks
VPN- or firewall-protected environments

Using it on a public instance is unsafe — and the documentation is intentionally explicit about that.

Security should be strong by default, but never magical.

Branding & UX improvements

While security was the main theme, a few smaller — but very practical — improvements landed as well.

Branding settings

LeafWiki now supports:

Custom site name
Logo
Favicon

This sounds small, but it matters a lot for internal tools.
Branding helps with adoption and trust — especially when LeafWiki becomes part of daily workflows.

Under the hood: safer foundations

Some less visible changes shipped in the background as well:

Atomic writes for critical files
Schema versioning and migrations
Improved SQLite FTS5 tokenization (e.g. C++, filenames)

None of these are headline features — but together they make upgrades safer and behavior more predictable.

About 2FA / TOTP (and why it’s not in yet)

A recent feature request asked about TOTP-based 2FA support.

Short answer:

Yes — it makes sense, especially for internet-exposed instances.

Longer answer:

LeafWiki still lacks a few core building blocks, such as:

Content versioning
Import / export
Conflict handling

Those come first.

Security is not a checkbox you tick once — it is an ongoing process.

The goal of v0.7.x was to lay a solid foundation before stacking more features on top.

The issue is open and tracked, and I’ll revisit it once the basics are in place.

Thanks

This release was shaped heavily by feedback and contributions from the community.

Thanks to everyone who uses LeafWiki, reports issues, and shares ideas — your feedback directly influences the direction of the project.

LeafWiki Devlog #7: v0.6.1 - Introducing Backlinks + Better Search (SQLite FTS5) 🌿

perber — Sat, 17 Jan 2026 18:47:59 +0000

Hi!

It’s time for another update on LeafWiki 🌿

The new version v0.6.1 focuses on two things you use constantly in a wiki:

Search — fuzzy search & improved ranking
Backlinks / link UX — introducing backlinks

If you’re new here: LeafWiki is a lightweight, self-hosted Markdown wiki built as a single Go binary.

It’s for people who think in folders, not feeds.

LeafWiki stores everything locally — Markdown files on disk, plus a small tree file for structure and metadata.

If LeafWiki disappears tomorrow, your content is still yours.

👉 GitHub: https://github.com/perber/leafwiki

Backlinks

Backlinks are one of those features that turn a wiki into a knowledge base.

They also enable something important: showing the impact of moves and renames - because in a real wiki, pages don’t stay static forever.

LeafWiki follows an explicit approach here (similar to working in an IDE):
when you rename or move a page, you can decide whether links inside Markdown should be updated as well.

(Automatic link updates are planned for a future release.)

Backlinks answer questions like:

“Where is this page referenced?”
“Which docs depend on this decision?”
“What’s connected to this topic?”

What’s included in v0.6.1 (Backlinks & Links)

Incoming backlinks per page
Outgoing link list
Broken links are tracked (so you can see what needs fixing) (A dashboard / overview for broken links is planned for a future release.)
The link section was intentionally made less visually dominant, so your page content stays the focus

My goal is to make link navigation feel useful without turning LeafWiki into a graph tool.

This is the first release where I’m properly introducing backlinks — and I’d love feedback on how you use them.

Search improvements for a Markdown based wiki

Search is a daily driver feature — if search feels unreliable, a wiki slowly turns into a graveyard.

In v0.6.1, I focused on making search feel more reliable and practical during day-to-day use.

🛠️ Under the hood: local SQLite FTS5 (no external services)

LeafWiki is file-based, so search needs to be fast without requiring a separate DB server or Elasticsearch.

LeafWiki uses a local SQLite FTS5 index (search.db) and keeps it up to date.

A few implementation details for devs & self-hosters:

Parallel indexing: Markdown files are indexed using a small worker pool
Markdown-aware indexing: headings are extracted and indexed separately so important sections rank well
Relevance ranking: results are ordered with BM25 weighting (title > headings > content)
Better UX: highlighted titles and snippets/excerpts generated directly by FTS
Fuzzy-by-default: normal queries get * wildcards automatically

(Optional: tiny schema snippet)

CREATE VIRTUAL TABLE pages USING fts5(
  title,
  headings,
  content,
  tokenize = "unicode61 tokenchars '-_/+#.'"
);

Feedback welcome

Backlinks can be a deep rabbit hole (graphs, tags, multi-references, etc.).

LeafWiki tries to keep it simple — but useful.

So I’d love to hear:

Do you use backlinks in your documentation or more for knowledge management?
Should the link section be more prominent, or is the subtle approach better?

Thanks for following along 🌿

Try it out: https://demo.leafwiki.com

If you like the project, check it out on GitHub: https://github.com/perber/leafwiki

LeafWiki Devlog #6: v0.5.2 - is out - dark mode and Markdown improvements

perber — Sun, 21 Dec 2025 14:48:36 +0000

I'm happy to announce that Leafwiki v0.5.2 is out.

This release introduces dark mode support.

With support for Mermaid diagrams, images, and HTML inside Markdown, Leafwiki can be used for project documentation, technical notes, and internal documentation for personal use and small dev teams.

What is Leafwiki

Leafwiki is a lightweight, self-hosted wiki engine built for developers who want a simple and reliable way to manage documentation.

It is a markdown-powered wiki: content is stored as plain Markdown, while Leafwiki itself takes care of structure, navigation, and rendering. The goal is to behave like a real wiki, just without unnecessary complexity.

How it works

At a high level, Leafwiki keeps things intentionally simple:

Content is stored as Markdown files (no vendor lock-in).
Page hierarchy and ordering are stored in tree.json (loaded into memory). Leafwiki can reorder and move pages, and updates the on-disk layout accordingly.
SQLite is used for search indexing and user management, so no external database is required.
Leafwiki is implemented as a single-page application (SPA). This allows fast navigation between pages and a smoother editing experience, without full page reloads.

Who Leafwiki is for

Leafwiki already works well as a personal wiki.

What's planned

In v0.6.0, Leafwiki will get backlinks, which will improve navigation and content discovery.
Team-related features, such as versioning, are planned for future releases, moving it closer to an internal documentation tool for small dev teams.

What's new in v0.5.2:

Dark mode support
HTML support in Markdown

I think the dark mode is already looking good.
From a code perspective, I previously had many inline styles inside components. In this version, those styles were moved into index.css, and configuration is overridden there.

This makes it easier to:

adjust styles for dark mode
introduce new colors
override Tailwind tokens in a single place

Overall, this simplifies theming and makes the codebase easier to maintain.

Project status

Leafwiki has reached 32 GitHub stars, which I’m genuinely happy about.
I’ve also received some early feedback from users, for example:

I use it for personal use, I find it attractive because the LeafWiki is light and fast.

Demo and source

Demo: https://demo.leafwiki.com
Repo: https://github.com/perber/leafwiki

Thanks for reading!
Feedback and issues are always welcome

The 3 small Wiki UX frustrations that pushed me to build LeafWiki

perber — Mon, 24 Nov 2025 20:50:52 +0000

This post is not meant as criticism of any existing tool.

LeafWiki itself is still in active development, and I’m sure I’ll eventually run into UX issues in my own project too — that’s normal.

But I want to describe the real workflow pains I experienced while using other wiki tools like Wiki.js, Confluence, and similar systems.

These small frictions kept interrupting my writing flow, and over time they motivated me to build LeafWiki as a simpler alternative for developers and teams.

I’m actively improving the UI and UX, and there are still things I want to polish — but the core philosophy stays the same:

Simple to run: No container, no database, just Go
Simple to host: You know where your data is
Simple to trust: Markdown is portable & future-proof

I chose Go specifically to keep LeafWiki a single, fast binary with no external dependencies.

Your knowledge shouldn’t belong to a database you maintain — it should belong to you.

1. I wanted to paste screenshots directly into the editor (Ctrl+V)

In the wikis I used before, adding a screenshot felt like a mini project:

Take screenshot
Open upload dialog
Choose the correct folder
Upload the file
Click the uploaded item to insert it into the page

Every time I tried to quickly document something, this tiny workflow broke my flow.

What I really wanted was the natural workflow developers use everywhere else:

Screenshot → Ctrl+V → done.

So in LeafWiki, pasting images directly into the Markdown editor automatically uploads them and inserts the correct Markdown link — with no dialogs and no mental friction.

Just write.

2. I kept having to choose folders just to upload the right file

Another small thing that slowed me down:

Before I could upload a file, I had to select a folder.

Yes, technically that makes sense - but on the user level, it felt unnatural.

My brain doesn’t think in terms of asset location. I write documentation and the asset should be part of the page. I think:

This file belongs to this page.

Not:

Let me browse to the correct folder for this file…

So LeafWiki stores assets per page.

If you upload an image while writing, it’s automatically attached to that page.

No folder selecting. No searching. No extra decisions.

3. I wanted to create pages directly in the tree where I’m thinking

This one bothered me more than it should:

I’d see exactly where a new page belongs in the structure - but to create it, I had to go somewhere else, usually a top-level menu.

That disconnect always broke my flow.

I also didn’t want to think about slugs during the creative flow.

Yes, I sometimes need to adjust slugs later, but that’s not the usual writing moment. (Of course changing slug is possible in LeafWiki.)

So LeafWiki lets you:

create pages directly in the tree
create pages from non-existing links
create pages from the 404 view
insert structure while thinking in structure

The wiki should adapt to how you think, not the other way around.

Why these small things matter

None of these issues are “big”.

They’re small, almost invisible UX friction points.

But they add up.

If you document things all day, these little interruptions make the tool feel heavy, slow, and mentally expensive.

LeafWiki tries to remove these tiny friction points:

Paste-to-upload (no dialogs)
Per-page assets
Structure where you think
Markdown editor
A single Go binary — easy to host, easy to trust

If that sounds interesting, you can try it here:

👉 Demo: https://demo.leafwiki.com

👉 GitHub: https://github.com/perber/leafwiki

Feedback, ideas, and discussions are always welcome

Self-Hosting a lightweight Wiki on Raspberry PI with Cloudflare Tunnel

perber — Sat, 08 Nov 2025 15:58:47 +0000

I’m the developer behind LeafWiki, a lightweight, Markdown-based Wiki that doesn’t require a database.
One of our users recently set it up on a Raspberry Pi, connected it to the Internet through Cloudflare Tunnel, and the setup was so clean that I decided to write a short guide about it.

He also published the documentation in the project repository:
Install LeafWiki on Raspberry PI

If you’re into self-hosted tools, this might be interesting to you.

Project Installation

To begin, you need to install LeafWiki.
Here is the quick install command:

curl -sL https://raw.githubusercontent.com/perber/leafwiki/main/install.sh -o install.sh && chmod +x ./install.sh && sudo ./install.sh --arch arm64

During installation, you’ll be asked for an admin password and a JWT secret.

That’s it 🎉
LeafWiki should now be running locally at:

👉 http://localhost:8080/

You can open that in your browser to confirm the installation.

Exposing LeafWiki to the Internet with Cloudflare Tunnel

At this point, LeafWiki is only accessible within your local network.
You could open ports on your router — but that’s risky and not ideal for security.

Instead, we’ll use Cloudflare Tunnel, a secure, zero-trust connection that lets you expose your local service to the Internet without opening any ports.

How it works

Cloudflare acts as a CDN (Content Delivery Network) sitting between the user and your server.

Traffic goes through Cloudflare, which then routes it safely to your local machine.
This way your IP stays hidden, and your connection stays encrypted.

In our case, the Cloudflare tunnel forwards traffic to LeafWiki running on your Pi — and exposes it as a subdomain of your domain, for example:

wiki.mysite.com

Domain Setup

You’ll need a domain name.
It can be managed through Cloudflare or any other registrar —
if your DNS is elsewhere, you’ll just need to point it to Cloudflare.

Creating a tunnel

Once your domain is ready:

Open the Cloudflare dashboard.
Go to Zero Trust -> Network -> Tunnels
Click Create a tunnel and choose Cloudflared
Give your tunnel a name.

You'll then reach the configuration page:

Configure the server (your Raspberry Pi)

After creating the tunnel, Cloudflare shows setup instructions for your device.
Connect to your Raspberry Pi via SSH and copy/paste the provided commands.

This will install Cloudflared, authenticate it, and connect your Pi to your Cloudflare account.

Expose your LeafWiki instance

Now that the tunnel is live, register your local app — in our case, LeafWiki

Protocol: HTTP
URL: localhost:8080

Save the configurtion

Cloudflare will now route external traffic (e.g. wiki.mydomain.com) directly to your LeafWiki instance — securely and without exposing your local IP. 🎉

Wrapping up

You now have:

LeafWiki running on your Raspberry PI
A secure Cloudflare Tunnle exposing it to the internet
Your own self-hosted lightweight wiki - accessible anywhere

If you want to try ityourself or checkout the project:
👉 GitHub Repository
👉 Live Demo

If you like the project and the idea,
⭐ drop a star on GitHub

LeafWiki Devlog #5: v0.4.9 - Mermaid Diagrams, Page Copy & Easier Setup 🚀

perber — Fri, 07 Nov 2025 18:17:02 +0000

Hey everyone 👋

After a few weeks of feedback and polishing, LeafWiki v0.4.9 is out!

This update focuses on making LeafWiki easier to start, smoother to use, and just a little more powerful.

🌿 What is LeafWiki?

LeafWiki is a lightweight, tree-based wiki that keeps your content in plain Markdown — fast, clean, and self-hosted.

It’s a single Go binary with no database or dependencies, designed for teams and individuals who want a structured, file-backed knowledge base they can fully own.

Run your knowledge base in 5 minutes.

Live Demo (resets hourly)
GitHub Repository

✨ What’s New in v0.4.9

🧭 Copy Pages (with Assets)

You can now duplicate entire pages, including all uploaded images and files.

Perfect for templates or similar documents.

🪄 Mermaid.js Diagram Support

You can now embed Mermaid.js diagrams directly inside Markdown pages using fenced code blocks:


```mermaid
graph TD
  A[Start] --> B[Write Markdown]
  B --> C[Render Mermaid Diagram]
  C --> D[Enjoy!]
```

LeafWiki automatically renders these diagrams in the page preview.

Improved Installer

A installation script was added to make it even simpler to set up LeafWiki on Linux or Raspberry Pi.

Try it in one line:

curl -sL https://raw.githubusercontent.com/perber/leafwiki/main/install.sh -o install.sh \
  && chmod +x ./install.sh && sudo ./install.sh --arch amd64 --jwt-secret=yoursecret

Or checkout the documentation

🌐 Live Demo Added

You can now explore LeafWiki without installing anything.

The public demo resets hourly — so feel free to experiment!

💬 A Few Words of Thanks

Big thanks to:

@Hugo-Galley for documentation and onboarding improvements
@magnus-madsen for feedback on hosting and UX
@schewara for the hint on Alpine Docker images

Community feedback has been a big part of shaping this release 💚

🧠 Why LeafWiki Exists

I wanted something between a static Markdown site and a full database wiki:

File-based and transparent
Still editable and searchable
Easy to host and maintain

So I built LeafWiki — a small Go application that manages Markdown pages in a true tree structure, supports uploads, and provides a built-in editor with live preview.

It’s not trying to be everything — just a fast, minimal wiki that values clarity over complexity.

🚀 Try It Yourself

🔗 Live Demo: demo.leafwiki.com

🐙 GitHub: github.com/perber/leafwiki

Your knowledge should live in files you own — not in a database you maintain.

LeafWiki - Finding Clarity in Open Source

perber — Sun, 26 Oct 2025 17:48:21 +0000

I’ve been working for a few months now on my vision of a developer-friendly Markdown wiki.

Maybe you’ve already seen one of my earlier posts about it.

At the beginning of an open-source project, the energy is wild.

You have big ambitions: replace Wiki.js, replace Confluence, build a simpler, cleaner alternative.

The idea for LeafWiki was straightforward:

Easy to self-host
Markdown-based content
No database
A lightweight tool for internal knowledge sharing

Just download the binary, run it, start writing.

That’s still the heart of it.

The early phase: feature, feature, feature

During the first months I built one feature after another:

Public pages sounded cool
Full Markdown file sync from disk sounded powerful
More features would make more people happy… right?

Well. I can’t achieve everything and keep the focus on the goal:

A wiki for developers without ops pain.

So for me it became clear:

Public pages aren’t necessary for an internal wiki
The internal structure should still be determined by tree.json, not the filesystem — which offers some benefits

A break and a new direction

In August, I took a small break.
While I wasn’t coding, something great happened:

⭐️ LeafWiki reached 16 GitHub stars

🐛 The first user-submitted issue arrived

My first real user, besides myself.

That felt unexpectedly amazing.

Their feature request was simple:

When clicking an internal link, automatically create the page if it doesn’t exist.

Absolutely logical. Very helpful.

I implemented it — and it felt great.

That interaction helped me clarify LeafWiki’s purpose:

This is a wiki for developers and internal teams — not a public website generator.

The closer LeafWiki gets to real developer workflows, the better it becomes.

What I decided to remove

I decided to remove these features from the roadmap:

Static public pages
Reading all content directly from Markdown files on disk

What's coming next

Copy Page — duplicate pages and assets
Mermaid support
Auto page creation (already done)

I think these are the right features to work on at the current state.

Do you want to help shape LeafWiki?

LeafWiki is still a young project — which means your feedback will help shape a developer-friendly wiki.

I’d love to hear from you:

What’s missing?
What feels unnecessary?
What is the one feature you think a developer wiki should have?

Drop a comment, open an issue — and maybe leave a ⭐️.

Every star motivates me more. 🙌

🔗 https://github.com/perber/leafwiki

Thanks for reading.

🐶 Dogfooding LeafWiki – Why Using Your Own Tool Matters

perber — Tue, 24 Jun 2025 21:20:19 +0000

"Eat your own dog food."

In other words: Use your own product.

That’s exactly what I did with LeafWiki – the Markdown-based wiki I’m building. I started writing its own public documentation using LeafWiki itself.

And as expected, a few things broke along the way. Which is great – because that's exactly the point of dogfooding.

You think your tool works – until you actually rely on it.

Real usage surfaces issues you'd never catch while just developing.

🧭 What is LeafWiki?

Quick version:

A Markdown-based wiki with a tree structure
Content lives as .md files in folders
No database, no cloud, no lock-in
Just a single Go binary you can run anywhere

The idea is to give devs and small teams a simple, self-hosted alternative to tools like Confluence or Wiki.js, without all the setup overhead.

🧑‍💻 Why I built it

I’ve used a lot of wikis – and honestly, most of them felt like too much.

Complex setup, clunky UI, full DB stack – or just... slow.

I wanted something that:

looks clean
runs fast
stores everything in plain Markdown
doesn’t tie me to a platform

Not trying to replace Confluence or Wiki.js completely – but for small teams, dev environments, or side projects, LeafWiki might be all you need.

So I built it in Go, made it a single binary, and made sure it works on everything from servers to Raspberry Pis.

⚙️ What LeafWiki can do (v0.4.3)

🌐 Public Pages
🔍 Full-Text Search (via SQLite)
📂 Tree Navigation
✍️ Markdown Editing with CodeMirror (Split View, auto-scroll)
🎨 Syntax Highlighting
📱 Mobile-Optimized UI
👥 Simple Role System (Admin / Editor)
📤 Asset Upload & File Management
🧱 No external db service

🧪 What I found while dogfooding

While writing LeafWiki’s docs inside LeafWiki, I ran into a few rough spots – most of which are already fixed for the upcoming v0.4.4 (dropping June 29):

❌ Bugs I ran into:

Slugs saved too early

→ If you typed fast and hit Enter, the slug wasn’t ready (roadma instead of roadmap).
Editor jumped to top after save

→ Classic React remount issue – annoying, but fixed.
Scroll position lost when navigating back

→ React router + scrollable divs = not friends by default.
Edits lost after token refresh

→ Access token expired silently; the refreshed token didn’t apply to the save.

Losing edits like that was especially frustrating – and definitely something I needed to fix.

✅ What dogfooding really taught me

Dogfooding is more than just testing – it forces you to experience the product like a real user.

Things that seemed fine during development became frustrating during actual writing.

Suddenly, a scroll jump broke focus.

Suddenly, saving wasn’t just a button – it had consequences.

Dogfooding gave me honest, immediate feedback.

It highlighted weak spots and helped me prioritize what really matters.

If you’re building a dev tool and haven’t used it for actual work yet: Do it.

It’s uncomfortable, but it makes everything better.

📣 What’s next?

I’m putting the finishing touches on the public docs, which will go live soon.

In the meantime:

🔗 github.com/perber/leafwiki
Try it out. It’s free, open source, and zero-setup.
Bug reports, feedback, or just saying hi – all welcome.

⚠️ Heads up:

LeafWiki is still very much in active development.

It works, and I use it daily – but if you're planning to use it in > production, be aware that things may still shift a bit over the > next few releases.

That said, early feedback is incredibly helpful right now.

Let me know what you think – or better yet:

Try writing your own docs with it. That’s how it gets better.

DEV Community: perber

Fourteen months of LeafWiki, in small moments

A quiet release nobody noticed

The issue that came after a long summer

Someone who said he'd help, then went quiet

A pull request I almost missed

Sergio, and the first person who kept paying

Posting it, for the first time

The post that actually moved the number

Two mentions I didn't ask for

Where that leaves things

I built a boring wiki on purpose

Three categories I decided not to compete in

The decision that shaped everything

What I said no to

What I cared about instead

Whether it was the right call

LeafWiki Devlog #10: v0.9.0 – no more broken links, lost edits, or overwritten changes

"Someone changed something last week — what did it look like before?"

"I moved a section and now half the links are broken"

"Two of us edited the same page and one overwrote the other"

"I shared this link and now it's dead because we restructured"

Shoutout boxes

Importer improvements

LeafWiki Devlog #9: v0.8.2 – Tree Improvements & Reverse Proxy Support

A quick recap: the 0.8 series

Reverse Proxy Support (--base-path)

Tree View usability improvements

What’s next

LeafWiki Devlog #8: v0.7.3 - Secure by Default: Authentication, Roles & Safer Self-Hosting

A quick reminder: what LeafWiki is

Why security became a priority now

Secure by default, flexible by design

Authentication & session handling

What this enables

Roles & access control

Escape hatches (and why they exist)

--allow-insecure

--disable-auth

Branding & UX improvements

Branding settings

Under the hood: safer foundations

About 2FA / TOTP (and why it’s not in yet)

Thanks

LeafWiki Devlog #7: v0.6.1 - Introducing Backlinks + Better Search (SQLite FTS5) 🌿

Backlinks

What’s included in v0.6.1 (Backlinks & Links)

Search improvements for a Markdown based wiki

🛠️ Under the hood: local SQLite FTS5 (no external services)

Feedback welcome

LeafWiki Devlog #6: v0.5.2 - is out - dark mode and Markdown improvements

What is Leafwiki

How it works

Who Leafwiki is for

What's planned

Project status

Demo and source

The 3 small Wiki UX frustrations that pushed me to build LeafWiki

1. I wanted to paste screenshots directly into the editor (Ctrl+V)

2. I kept having to choose folders just to upload the right file

3. I wanted to create pages directly in the tree where I’m thinking

Why these small things matter

Self-Hosting a lightweight Wiki on Raspberry PI with Cloudflare Tunnel

Project Installation

Exposing LeafWiki to the Internet with Cloudflare Tunnel

How it works

Domain Setup

Creating a tunnel

Configure the server (your Raspberry Pi)

Expose your LeafWiki instance

Wrapping up

LeafWiki Devlog #5: v0.4.9 - Mermaid Diagrams, Page Copy & Easier Setup 🚀

🌿 What is LeafWiki?

✨ What’s New in v0.4.9

🧭 Copy Pages (with Assets)

🪄 Mermaid.js Diagram Support

Improved Installer

🌐 Live Demo Added

💬 A Few Words of Thanks

🧠 Why LeafWiki Exists

Reverse Proxy Support (`--base-path`)

`--allow-insecure`

`--disable-auth`