DEV Community: perber

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.

LeafWiki Devlog #4: v0.4.0 - A Markdown Wiki is now ready for Dogfooding

perber — Fri, 20 Jun 2025 17:37:07 +0000

Hey 👋

just wanted to share a quick update on my side project – LeafWiki, a Markdown-based wiki built with developers in mind.

🌿 What is LeafWiki?

LeafWiki aims to be a lightweight Markdown wiki for developer teams. No cloud lock-in, no database, no unnecessary overhead.

Just a single binary that lets you create, search, and edit Markdown files — all stored directly on your local disk.

📸 Here’s a quick screenshot while writing this post inside LeafWiki itself:

🗂️ And a glimpse of the built-in asset manager:

✅ What’s new in v0.4.0?

With this release, the project is now ready for real dogfooding – meaning I’ve started using it internally for my own documentation needs.

1. 📱 Mobile-optimized UI

The interface now works on smartphones and tablets.

2. 🔍 Full-text search (SQLite-based)

A custom module scans all Markdown files and builds a fast local search index.

3. ✍️ Editor improvements

The editor now supports hotkeys for bold, italic, ## headings, and more — no bloated WYSIWYG needed.

🤝 Feedback & Chat

I’d love to hear your feedback, ideas, or suggestions!

→ Project: github.com/perber/leafwiki

→ Chat: Discord

Thanks for reading
– Patrick

LeafWiki now supports ARM64 – run your Markdown wiki on Raspberry Pi

perber — Tue, 10 Jun 2025 19:58:27 +0000

LeafWiki is a lightweight, self-hosted Markdown wiki — tree-based, database-free, and easy to run as a single Go binary.

With version v0.3.4, we're excited to announce native ARM64 support!

🌿 What is LeafWiki?

LeafWiki is designed for developers and teams who want:

Clean Markdown files organized in folders
A real tree structure (not a flat list of pages)
No database – just files on disk
A modern UI with live preview
Easy to self-host

👉 GitHub Repo

👉 Latest Release

✅ What’s new in v0.3.4?

LeafWiki now builds and runs natively on:

✅ Raspberry Pi 4/5 with 64-bit OS
✅ Linux amd64
✅ Windows x86_64 (via .exe)

No emulation or QEMU needed — just download the binary and run!

wget https://github.com/perber/leafwiki/releases/download/v0.3.4/leafwiki-v0.3.4-linux-arm64
chmod +x leafwiki
./leafwiki --jwt-secret=your-secret --admin-password=your-password --port=8080

🧪 Real-World Use Cases

🏡 Personal knowledge base on Raspberry Pi
🌍 Offline docs on embedded/field devices

🔄 Still in Development — Feedback Wanted!

LeafWiki is still under active development. We're currently working on v0.4.0, which will include:

Full-text search
Table of Contents
Public Pages
Better mobile layout

Your feedback, use cases, and questions are very welcome.

Open an issue on GitHub, or comment here 🙌

LeafWiki Devlog #3: v0.3.0 - Multi-File Uploads, Asset Renaming & Syntax Highlighting

perber — Mon, 02 Jun 2025 17:10:22 +0000

It hasn't been that long since I released LeafWiki v0.2.0, but I’ve already pushed out a small but useful update: v0.3.0.

🌿 What is LeafWiki?

LeafWiki is a simple, file-based wiki system.

No database required
Single static Go binary
Everything stored as plain Markdown files – no vendor lock-in

Main features include:

Lightweight role management (editor/admin)
Tree-based page structure
Markdown editing with CodeMirror (live preview + toolbar)
Asset management (upload images, files, etc.)

✨ What’s new in v0.3.0?

✅ Multi-file upload in the Asset Manager – finally!
✅ Renaming assets (completely forgot that in the last release 😅)
✅ Syntax Highlighting in Code Block
✅ No more HTML caching issues – changes now show up instantly in edit and view mode

🚀 Coming in v0.4.0:

🔍 Full-text search

You can find the project on GitHub here:

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

If you have feedback, ideas, or just want to say hi – I’d love to hear from you.

Thanks for following along on the journey!

DEV Community: perber

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

🚀 Try It Yourself

LeafWiki - Finding Clarity in Open Source

The early phase: feature, feature, feature

A break and a new direction

What I decided to remove

What's coming next

Do you want to help shape LeafWiki?

🐶 Dogfooding LeafWiki – Why Using Your Own Tool Matters

🧭 What is LeafWiki?

🧑‍💻 Why I built it

⚙️ What LeafWiki can do (v0.4.3)

🧪 What I found while dogfooding

❌ Bugs I ran into:

✅ What dogfooding really taught me

📣 What’s next?

LeafWiki Devlog #4: v0.4.0 - A Markdown Wiki is now ready for Dogfooding

✅ What’s new in v0.4.0?

1. 📱 Mobile-optimized UI

2. 🔍 Full-text search (SQLite-based)

3. ✍️ Editor improvements

🤝 Feedback & Chat

LeafWiki now supports ARM64 – run your Markdown wiki on Raspberry Pi

🌿 What is LeafWiki?

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

`--allow-insecure`

`--disable-auth`