Why we built Nibleaf for teams that want to own their docs

Documentation tooling has quietly turned into rent. Somewhere along the way, publishing a docs site — a folder of Markdown rendered with a search box — became a subscription with per-seat pricing, usage meters, and a dashboard you can never take with you. Your content lives on someone else's servers. Your readers' traffic flows through someone else's analytics. And when pricing changes, your options are pay up or migrate.

We built Nibleaf to combine a browser editor, Markdown content, publishing, search, and Arabic support in one product. The codebase is AGPL-3.0 licensed, the repository and container release are public, and the managed cloud is available in beta.

This post covers why we built it and what is in the box.

Why docs tooling became rent

To be fair to the incumbents: they are good products. Mintlify keeps MDX source in your Git repository and now offers Enterprise teams a self-hosted custom frontend, while its content engine, editor, search, and AI remain managed services. GitBook has a capable hosted editor and publishes an open-source reader renderer that can be self-hosted, although GitBook says that route is not recommended or supported and it does not include the hosted workspace or editor. Nibleaf's distinction is a public full-stack deployment that includes authoring, publishing, search, analytics, and the reader. We break down the boundaries in Nibleaf vs GitBook, Nibleaf vs Mintlify, GitBook's public renderer, and Mintlify's custom-frontend announcement.

The open-source side of the spectrum has the opposite problem. Docusaurus is excellent and MIT-licensed, but it is a static site generator, not a platform: there is no hosted editor for non-developers, search usually means wiring up an external service, and every contributor needs Git and a build pipeline. We compare the trade-offs honestly in Nibleaf vs Docusaurus.

Nibleaf's premise is that you should not have to choose. A documentation platform can combine an editor, publishing, search, analytics, and custom domains while keeping content portable and its codebase under an open-source license.

An editor that writes Markdown, not a format you rent

The core design decision in Nibleaf is the editor. It is a Notion-style WYSIWYG editor — blocks, a slash menu, inline formatting — because most people who write documentation are not developers, and asking a support engineer or product manager to hand-edit MDX in a pull request is how docs go stale.

But WYSIWYG editors have a bad reputation for a reason: most of them persist an internal document format, and your content is only as portable as their export button. Nibleaf's editor round-trips plain Markdown. What you type in blocks is stored as Markdown; what is stored as Markdown loads back into blocks. There is no proprietary intermediate format at any point. MDX components — callouts, tabs, code groups, and the rest — are supported inside the same flow.

Writing is collaborative, too: each site has a team with owner, admin, and editor roles, and reviewers can leave comments anchored to specific blocks instead of pasting screenshots into Slack.

Publishing is versioned, and readers never see drafts

Nibleaf separates writing from publishing. Every publish produces an immutable snapshot of your site: the pages, the navigation tree, the settings, all frozen at that moment. Readers are always served a complete snapshot, never a half-written page — you can edit for a week and nothing changes on the live site until you publish.

Because snapshots are immutable, rollback is trivial: republish a previous snapshot and the live site is instantly back to a known-good state. No cache invalidation dance, no rebuild pipeline to babysit.

Search that ships in the box

Docs search is where hosted platforms usually earn their subscription and static generators usually send you to a third party. Nibleaf keeps a built-in Orama full-text and fuzzy path behind the Cmd+K interface, with no Algolia account or crawler required. Source main also includes an optional tenant-filtered Qdrant hybrid path and opt-in grounded answers. Operators start that path in shadow mode, supply and evaluate their chosen embedding and answer providers, and retain SEARCH_RUNTIME=legacy as the immediate rollback. The checksummed v0.1.2 self-hosted artifact remains on the built-in path until a later image is published.

Search selects an Arabic tokenizer for Arabic projects, applies spelling normalization, and adds conservative light morphology for common prefixes, attached pronouns, and plural or dual forms. Exact tokens retain the strongest ranking, while code, mixed identifiers, short words, and ambiguous terms are protected from stemming.

Arabic-first, not RTL-as-an-afterthought

Most documentation platforms treat right-to-left languages as a CSS patch: flip the layout with dir="rtl" and hope. If you have ever shipped Arabic docs, you know the reality — mirrored icons that should not mirror, code blocks fighting the text direction, search that returns nothing, navigation trees that assume English.

Nibleaf was designed bilingual from the start:

Capability	How Nibleaf handles it
Content structure	Per-language page trees — Arabic docs are not translations bolted onto an English tree
Layout	First-class RTL rendering in the reader, not a flipped stylesheet
Search	Arabic tokenizer in the built-in index
SEO	hreflang annotations generated per language
Product UI	Dashboard and reader localized in English and Arabic

If your users are in the Middle East and North Africa — or you are a global company that keeps deprioritizing the Arabic docs because the tooling fights you — this is the platform gap Nibleaf exists to close.

The rest of a real platform

The features that make hosted docs products feel finished are present in the managed product:

• Custom domains with guided DNS verification, plus wildcard project subdomains out of the box.
• SEO built in: server-side rendering, canonical URLs, Open Graph and Twitter cards, JSON-LD, sitemaps, robots controls, and per-page noindex.
• Product analytics: page views, unique visitors, top pages, top searches, and device and language breakdowns are collected by the Nibleaf application. The hosted service also runs behind Cloudflare, which processes delivery and security telemetry as described in the privacy policy.
• Bring your own storage: assets go to any S3-compatible store (AWS S3, Cloudflare R2, Backblaze B2) or the bundled storage service.

Cloud beta and self-hosting

Nibleaf Cloud is the usable option today. It is in free beta, with no paid plan currently offered. Details are on the pricing page, and you can create a workspace to evaluate the editor and publishing workflow.

The codebase is licensed under AGPL-3.0. The public repository, pinned GHCR release, and guided Docker Compose installer can be fetched without private credentials. The self-hosting guide covers the operational work that remains yours: TLS, DNS, backups, monitoring, and restore testing.

Where Nibleaf stands today

Nibleaf is in beta, and we would rather be precise than promotional about that. The editor, versioned publishing, search, i18n, domains, SEO, and analytics described above are shipped and running in production. Mintlify has years of head start on breadth, and Docusaurus has an enormous plugin ecosystem; if those strengths are what you need today, the detailed Nibleaf vs Mintlify comparison lays out exactly where each tool wins.

What Nibleaf offers now is a browser editor over Markdown, versioned publishing, built-in search, multilingual sites, a managed beta, and a public self-hosted release. Content can be exported as Markdown.

How to start

• Cloud: sign up for a free beta workspace at nibleaf.com.
• Self-hosting: follow the deployment guide, then test DNS, backups, and restoration on a disposable server.

If you have been paying rent on a folder of Markdown, come take a look.