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.
Top comments (0)