Free knowledge base software: the limits that decide which one you pick

The short version

• Free knowledge base software comes in three forms: a free tier, an open source tool you host, and a static site generated from a repository.
• Free tiers rarely limit pages. They limit editors, file size, permissions and export.
• Notion's free plan caps an individual file upload at 5 MB, against 5 GB on its paid plans.
• Self-hosting a wiki to avoid a subscription trades a predictable bill for unpredictable hours.
• No knowledge base creates knowledge. Most of the missing context is still in people's heads.

What does 'free' actually mean in knowledge base software?

Three different things get sold as free, and they fail in different ways. There is the free tier of a commercial product, which is a working product with features held back. There is open source you install yourself, which costs nothing to licence and something to run. There is a static site built from text files in a repository, which is free in every sense if your writers are comfortable in Git. Choose the category first. The tool matters less than the category you are in.

Free tiers are the easiest to start and the easiest to regret. You get a real editor, real search and usually more pages than you will ever write. What you do not get is the thing you need in month eight, which is normally a permission boundary, a larger upload, a second workspace or an export that comes back in one piece. The limit that catches you is rarely the one advertised on the landing page.

Open source you host is free of licence cost and nothing else. BookStack, Wiki.js, DokuWiki and MediaWiki are all genuinely free software with real communities behind them. They also want a server, a certificate, backups you have restored at least once, an upgrade path and somebody who notices when the search index stops updating. That work is small per month and never zero, and it tends to land on whoever is least able to refuse it.

A static site is the option people forget. Markdown files in a repository, built with something like Docusaurus, served by any static host. Review before publish, full history and diffs come free because Git already does them. The cost is that editing is a pull request, so the first person outside engineering who needs to fix a typo is the real test of the idea.

Which free tier limits actually bite?

Not the page count. Almost every free tier will hold more pages than a small company writes in two years. The limits that bite are about people, files and getting out again.

Editors against viewers is the first one. Many free plans count anyone who can edit against a small seat limit, while read-only guests are cheap or unlimited. That is fine until the support team wants to correct the article they just used, and the correction costs a seat. The result is a knowledge base that only two people can fix, which is how content goes stale.

File size is the second, and it is the limit nobody reads. Notion's free plan allows uploads of up to 5 MB per file, against up to 5 GB on its Plus, Business and Enterprise plans. Attachments are where knowledge bases get heavy: a scanned contract, a screen recording, an exported deck. Check the number before somebody discovers it mid-task.

Permissions are the third. A free workspace often has exactly one boundary, in or out. If salary bands need to be visible to three people and the onboarding guide needs to be visible to everyone, confirm that per-page or per-space permissions exist on the free plan, not merely somewhere in the product.

Export is the fourth and the one to test immediately. Not whether an export button exists, but what comes out of it. Run a full export, open it in something else, and look at whether headings, tables, internal links and attachments survived. A knowledge base you cannot leave is not free, whatever it costs per month.

What does each kind of free actually cost?

Is self-hosting a wiki actually cheaper?

Usually not, for a team under about twenty people. The subscription is the visible cost and the hours are the hidden one, and the hours are paid in attention by the person who can least spare it.

Price it honestly. The install is an afternoon and it is not the expensive part. The expensive part is the upgrade in month five, the certificate renewal that fails at the weekend, the spam accounts on an open signup page, and the backup you discover is empty on the day you need it. If you want to cost those hours rather than guess at them, median pay for software developers is published by the US Bureau of Labor Statistics and your own payroll is better still.

There are good reasons to self-host anyway. Content you are not willing to put into someone else's system. A data residency rule you have to meet. An existing server and someone who already keeps it patched. 'We will save the subscription' is not one of those reasons, unless you have counted the hours and still prefer them.

Buying rather than running things also gets more common as organisations grow. Eurostat's 2025 survey put cloud computing use at 52.74% across EU enterprises with ten or more employees, 66.78% among medium enterprises and 84.67% among large ones, which puts the smallest firms below that overall average. That is the pattern you would expect: fewer people to run a server, and less appetite for another thing to patch.

How much should you trust the statistics in a buyer's guide?

Less than the guides would like. Most 'teams waste X hours a week' figures in this category come from a vendor survey, and the vendor sells the cure. That does not make the research worthless. It makes it evidence about a market rather than evidence about your team.

Two examples, both real research, both with limits worth knowing. Atlassian's State of Teams 2025 surveyed 12,000 knowledge workers and 200 executives, and the page states that sample but not the fielding dates or the countries. Zendesk's CX Trends 2026 reports two global surveys, 6,182 consumers and 5,115 CX professionals across 22 countries, and does not publish fielding dates either. Neither tells you how much time your own people lose looking for things.

You can measure that yourself, and the question is simple enough to copy. Stack Overflow's 2026 developer survey asks 12,006 respondents for a free-numeric answer to 'In a typical week, how much time do you spend looking for information you need to do your work?'. Ask your own team that before you choose a tool, then again three months later. If the second answer is no better, the tool was not the problem.

Is the problem the software, or the writing?

The writing, most of the time. In Stack Overflow's 2026 survey, asked which things make it difficult to get the context they need for work, 60.9% of 12,374 respondents picked 'important context lives in people's heads'. No software moves it out of there. Someone has to write it down, and nothing in a free trial changes who that is.

This is why the free against paid question matters less than it looks. A free wiki that three people update every week beats a paid one that nobody has touched since the trial ended. Decide who writes, when they write, and what happens when they do not, before you compare feature tables.

The practical version is small. One named owner per area. Write the page the second time the question gets asked, not during a documentation week that never arrives. Delete anything a year old that nobody has opened. Forty current pages are more useful than four hundred of uncertain age, and much easier to put an assistant on top of later.

What should you check before you commit?

Check the exit, the permissions and the machine access, in that order. Everything else is recoverable. Those three decide whether you can change your mind in two years without a project.

Do it on the comparison table, not the marketing page. Vendors describe the product on one and the free plan on the other, and the free plan column is the one you are buying.

Which lines on the pricing page matter?

• •Whether editors and viewers are counted differently, and what an editor seat costs on the first paid tier.
• •The maximum size of a single file upload, and what the product does with one that is too big.
• •Whether per-page or per-space permissions exist on the free plan, not just in the product.
• •What a full export produces, and whether attachments and internal links come with it.
• •Whether the free plan has an API at all, and what it is rate limited to.
• •How far version history goes back, and whether you can restore a page somebody deleted.
• •What public sharing gives you, including whether a custom domain is paid only.

Is a free tier enough for a customer-facing help centre?

Sometimes, and the paywall tends to sit close to where you need it. A public help centre usually wants a custom domain, your own branding and some sense of which articles answered the question. Those are common first upgrades, so check each one before you write fifty articles against them.

The internal and public cases also pull in different directions. An internal wiki wants permissions and good search. A help centre wants a clean URL per article, a structure customers can navigate, and a way to retire a page without breaking links. Running both out of one free workspace is the usual compromise, and it works until the first customer reaches an internal page through a shared link.

When does free stop being the right answer?

When the content starts carrying risk, or when a machine has to read it. Content that needs an audit trail, per-document permissions or a named owner for compliance reasons fits badly on a plan with one permission boundary. Paying also buys somebody to escalate to, which is worth something on the day search stops returning results.

The retrieval case is the one teams hit now. If the next step is an assistant that answers questions over your own documents, you need a stable identifier for each document, permissions an API can resolve for the person asking, and bulk access to content that does not involve scraping rendered pages. Free plans often fail the last two quietly, and you find out once the content is already inside.

None of this argues for paying early. It argues for picking a free tool whose paid version you would genuinely accept, and testing the export while the content is still worthless.