How to Build a Corporate Wiki
A new hire joins the company and spends the first week asking the same questions over and over: where is the report template, who approves the vendor contract, how do I get access to the staging server. Coworkers answer, get pulled away from their own work, and a month later someone else asks the exact same thing because the answer lived in a Slack thread nobody can find anymore.
A corporate wiki solves this. It is an internal website where a company keeps instructions, policies, process documentation, and answers to recurring questions. An employee opens it, finds the right page, and gets the answer without pinging a coworker.
This kind of knowledge base is not just for engineering teams. Sales uses it for scripts and pitch decks, finance for expense policies, HR for onboarding checklists. The rule of thumb is simple: once a company passes ten or fifteen people and information keeps getting lost in chat history and personal folders, a wiki starts paying for itself.
Why This Matters Now: Atlassian Is Winding Down Confluence Data Center
For years, the default answer to “what should we use for internal documentation” was Confluence. Atlassian’s wiki product became the industry standard for engineering docs and shared knowledge bases across companies of every size.
That default is changing. Atlassian has confirmed that Confluence Data Center, the self-hosted version companies run on their own infrastructure, is being phased out. New Data Center licenses stop selling on March 30, 2026, existing customers can renew until March 30, 2028, and the product reaches full end of life on March 28, 2029, after which instances become read-only. On top of the sunset timeline, Data Center pricing has gone up roughly 15 percent even as the product is being retired, which adds budget pressure for teams that planned to ride it out a while longer.
The push is toward Confluence Cloud, and for many teams that works fine. But Cloud comes with per-user pricing that scales fast, less control over customization, and data that lives on Atlassian’s infrastructure rather than the company’s own. Teams that want to keep the flexibility and cost structure of a self-managed wiki are looking at open source alternatives they can run themselves, and that is the path this guide walks through.
Hosted Service or Self-Hosted Wiki: Choosing Your Approach
There are two ways to set up a corporate wiki.
The first path is a hosted SaaS product. Sign-up takes minutes, the vendor handles updates and support, but the company pays a per-user monthly fee indefinitely and its data lives on someone else’s infrastructure.
The second path is a self-hosted wiki on a server the company controls. An open source engine runs on a rented VPS, the company owns its data outright, and the monthly cost is a fixed server bill rather than a fee that scales with headcount. The tradeoff is that someone on the team needs to handle setup and basic maintenance.
The self-hosted path makes the most sense for teams that want full control over their infrastructure, work with sensitive internal data, or simply want predictable costs once the team grows past twenty or so people. The rest of this guide covers that path step by step.
How a Wiki Actually Works
Think of a wiki as a shared folder of documents, except every page keeps a full history of changes and everything is searchable by content, not just by file name.
Pages are the basic unit. They group into sections by topic: onboarding, engineering docs, department policies. Every page tracks who edited it and when, so if something breaks you can roll back to a previous version instead of trying to remember what changed.
Search works across the full text of every page, not just titles, so an employee can find the right answer even without knowing exactly what the page is called. Permissions let admins restrict who can view or edit specific sections, which matters for anything touching compensation or personal employee data.
Comparing Popular Wiki Platforms
Which engine makes sense depends on team size and how comfortable someone on staff is with server administration.
Simpler tools like BookStack and DokuWiki work well for teams without a dedicated technical person. More flexible engines like Wiki.js or MediaWiki offer more power but need closer attention to updates and compatibility. Docmost leans toward a modern, Notion-style editing experience but needs noticeably more server resources to run comfortably.
The table below summarizes the main options.
| Engine | Stack | Server Requirements | Best For |
|---|---|---|---|
| Wiki.js | Node.js, PostgreSQL | 1-2 vCPU, 1.5+ GB RAM | Technical teams that want a flexible editor |
| BookStack | PHP, MySQL/MariaDB | 1 vCPU, 1+ GB RAM | Non-technical teams that want a simple structure |
| Docmost | Node.js, PostgreSQL | 2 vCPU, 4-8 GB RAM | Teams that want a modern, Notion-style editor |
| MediaWiki | PHP, MySQL/MariaDB/PostgreSQL | 1-2 vCPU, 1+ GB RAM | Large teams with complex content structures |
| DokuWiki | PHP, no database | 1 vCPU, 512+ MB RAM | Small teams that want the simplest possible backups |
This guide walks through BookStack. It runs on a simple two-container stack, organizes content in a hierarchy anyone can understand on sight, and has a low learning curve for non-technical staff.
What You’ll Need Before You Start
Before diving into setup, here is the short list of what to have ready.
You will need a VPS with 2 vCPUs, 2 to 4 GB of RAM, and 20 to 40 GB of NVMe storage. That configuration comfortably handles a team of several dozen people with room to grow. Beyond that, you need a clean Ubuntu install, a domain name for the wiki, and 15 to 30 minutes of uninterrupted time.
Spinning up a VPS with a ready Ubuntu image takes a few minutes, and from there the server is ready for Docker and the wiki engine itself.
Step-by-Step: Deploying BookStack on a VPS with Docker
Here is the full walkthrough, from connecting to a fresh server to a working wiki with a domain and HTTPS.
Connect to Your Server and Install Docker
Connect to the server over SSH:
ssh root@your_server_ipUpdate the package list and install Docker along with the Compose plugin:
sudo apt update
sudo apt install docker.io docker-compose-plugin -yDocker packages the app with all its dependencies into an isolated container. Updating or moving the wiki to a different server later comes down to a couple of commands instead of rebuilding the environment by hand.
Confirm Docker installed correctly and is running:
sudo systemctl status dockerWrite the docker-compose.yml for BookStack and MySQL
Create a project folder and the configuration file:
mkdir bookstack && cd bookstack
nano docker-compose.ymlPaste in a configuration with two services, BookStack itself and a MySQL database:
version: "3"
services:
bookstack:
image: lscr.io/linuxserver/bookstack
container_name: bookstack
environment:
- PUID=1000
- PGID=1000
- APP_URL=http://your_domain
- DB_HOST=bookstack_db
- DB_PORT=3306
- DB_USER=bookstack
- DB_PASS=strong_password
- DB_DATABASE=bookstackapp
volumes:
- ./app_data:/config
ports:
- "6875:80"
restart: unless-stopped
depends_on:
- bookstack_db
bookstack_db:
image: lscr.io/linuxserver/mariadb
container_name: bookstack_db
environment:
- PUID=1000
- PGID=1000
- MYSQL_ROOT_PASSWORD=strong_root_password
- MYSQL_DATABASE=bookstackapp
- MYSQL_USER=bookstack
- MYSQL_PASSWORD=strong_password
volumes:
- ./db_data:/config
restart: unless-stoppedReplace the placeholder passwords with your own before starting the stack, leaving the defaults in place is not something to skip.
Start the Containers and Log In for the First Time
Start both containers in the background:
docker compose up -dWatch the logs while the first database migration runs, it takes about a minute:
docker compose logs -f bookstackHow fast that first startup and any later container restarts go depends heavily on disk speed. On a VPS with NVMe storage, such as the ones offered by Serverspace, container rebuilds and restarts finish in seconds rather than minutes, which becomes noticeable every time you update the engine.
Open http://your_server_ip:6875 in a browser and you will land on the login screen. The default first-login credentials are admin@admin.com with a password of password, and both should be changed immediately from the profile settings once you are in.
Set Up a Domain and HTTPS
A production wiki needs a domain name instead of a raw IP address, plus an HTTPS certificate. The simplest route is putting a reverse proxy like Nginx or Caddy in front of BookStack and pulling a free certificate through Let’s Encrypt.
Here is a basic Nginx config that proxies requests to the BookStack container:
server {
listen 80;
server_name wiki.yourdomain.com;
location / {
proxy_pass http://127.0.0.1:6875;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}Once the proxy is in place, issue a certificate with certbot and enable an automatic redirect from HTTP to HTTPS.
Structuring Your Wiki: Sections, Permissions, Owners
BookStack organizes content in a hierarchy that most people understand on first look: shelves group books by topic, books split into chapters, and chapters hold individual pages. Even staff who have never touched a wiki tool pick this up fast.
Before filling it with content, define a handful of top-level shelves, something like onboarding, engineering docs, and department policies. Every section needs an owner who checks it stays accurate. A section with no owner drifts out of date fast, and once people stop trusting a page they stop checking it at all.
In the permissions settings, split staff into roles: some can only read, others can edit specific sections. This matters most for anything touching salary bands or personal employee information, lock those down from day one rather than after something leaks.
Start with the ten questions new hires ask most often rather than trying to map out a perfect hundred-page structure up front. The wiki grows naturally from there as staff propose new topics themselves.
Data Ownership and Access Control: What to Consider
Once a wiki holds anything beyond generic how-to pages, employee names, contact details, org charts, sometimes internal financial or client information, it stops being just documentation and starts being data the company is responsible for protecting.
This is where self-hosting has a real advantage over a multi-tenant SaaS product. The data sits on infrastructure the company controls, not spread across a vendor’s shared environment. For teams in regulated industries, healthcare with HIPAA obligations, finance, or any company that needs to answer a SOC 2 audit question about where internal data physically lives, that level of control is often the deciding factor over a hosted alternative.
Practically, this means picking server infrastructure with clear data residency and dedicated resources rather than assuming a cheap shared host is good enough once sensitive information is involved. A VPS with dedicated, isolated resources gives a straightforward answer when someone asks exactly where the company’s internal knowledge base lives.
Pros and Cons of a Self-Hosted Wiki
Here is a quick breakdown of the tradeoffs covered so far.
Advantages:
- Full ownership and control over company data.
- No per-user monthly fee, just a fixed server cost.
- Easier to answer data residency and compliance questions.
- Complete flexibility to match the setup to internal processes.
Drawbacks:
- Server maintenance, updates, and backups fall on the team.
- Requires at least basic technical comfort to set up and maintain.
- Engine and dependency updates need to be tracked manually.
- Growing usage may eventually require bumping up server resources.
Practical Use Cases
Five situations where a corporate wiki earns its keep.
New hire onboarding. A section answering the most common first-week questions cuts ramp-up time and takes the load off coworkers who would otherwise explain the same thing to every new hire individually.
Engineering documentation. Access instructions, architecture notes, and incident runbooks live in one searchable place instead of scattered across private chat threads and someone’s personal notes app.
Policies for non-technical departments. Finance, HR, and sales document approval workflows, templates, and internal processes that would otherwise get passed down verbally from person to person.
Internal support knowledge base. Customer support and success teams keep a library of answers to recurring tickets, which speeds up ramp time for anyone new to the team.
Preserving expertise before people leave. When a specialist moves on, their knowledge stays written down instead of walking out the door with them, which matters most for highly specialized roles that are hard to backfill.
Common Mistakes When Setting Up a Corporate Wiki
A handful of mistakes show up again and again in companies setting up a wiki for the first time.
Picking an engine without checking server requirements. A team picks something resource-heavy like Docmost without confirming it needs 4 to 8 GB of RAM, then runs into performance problems. The fix is simple: check the engine’s requirements before renting the server, not after.
No owner for a section. A wiki with nobody responsible for it fills up with outdated pages, and staff stop trusting it. The fix: assign an owner to every major section from the start.
Sections nested too deep. If it takes five clicks to reach a page, nobody bothers looking for it. The fix: cap nesting at two or three levels.
No database backups. A server failure wipes out the entire knowledge base if nothing was backed up. The fix: automate a daily backup of the database and file storage.
Ignoring where sensitive data lives. A team adds employee contact info and org charts without checking the server’s location or ownership model. The fix: treat any page with personal or sensitive data as something that needs a clear data residency answer.
No access controls. Everyone in the company can see salary bands and HR documents because permissions were never configured. The fix: set up role-based access before launch, not after the first incident.
Writing in overly formal language. Policy pages get written in dense corporate language that is a chore to read. The fix: write the way you would explain something to a coworker directly.
Conclusion: Where to Start and How to Keep It Going
A corporate wiki works best when nobody tries to make it perfect on day one. Pick an engine that fits the team’s size, rent a server sized for the load, get BookStack running in about half an hour, and start with the ten questions new hires ask most often, that is the whole playbook covered in this guide.
From there it grows on its own. Staff propose new topics, section owners keep things current, and questions like “where’s the contract template” stop eating into everyone else’s day.
FAQ
Is BookStack free to use for a business?
Yes. BookStack is open source under the MIT license, so there is no licensing fee regardless of company size or number of users. The only ongoing cost is the server it runs on.
Can I migrate content from Confluence into a self-hosted wiki?
Most open source wiki engines support importing content through Markdown or HTML exports. Migration effort depends on how much custom formatting or how many attachments the existing Confluence space has, simple text-heavy spaces migrate faster than pages full of macros and embedded widgets.
How often should a self-hosted wiki be backed up?
A daily automated backup of both the database and any uploaded files is a reasonable baseline for most teams. For a wiki that changes constantly throughout the day, some teams add a second backup pass in the evening as extra insurance.
What’s the difference between a wiki and a document management system?
A wiki is built for collaborative, linked pages that anyone with access can edit directly in a browser. A document management system is built around discrete files, version control, and formal approval workflows. Many companies end up using both, a wiki for living documentation and a DMS for signed contracts and formal records.
Do I need a dedicated server, or is a VPS enough?
For the vast majority of teams, a VPS is more than enough. A dedicated server only becomes worth the extra cost once the wiki serves a very large organization with heavy concurrent traffic or specific compliance requirements that call for fully isolated hardware.
