Self-Hosted Wiki for Project Documentation: How to Keep It Beside Your Tracker
Set up a self-hosted wiki beside your tracker: what goes where, how to link tickets to pages, how to limit access by project, and how to export your docs.
TL;DR
- A tracker tells you where the work stands, but it's a poor place to keep briefs, decisions and runbooks. A wiki next to the tracker gives them a place of their own.
- With Docmost, that wiki runs on servers you control, and your IT team looks after hosting, backups and upgrades.
- Spaces, groups and roles let you limit each project's pages to the people working on it.
- Linking each ticket to its page keeps the two connected, and Markdown and HTML export means you can take your docs with you.
Project documentation holds some of a company's most sensitive information: the brief for where a product is heading, notes from client calls, the reasoning behind decisions and the steps for getting into production systems. If those pages end up in whatever tool the team happened to start with, nobody may know where the data is stored or who can open it until something goes wrong. A contractor leaves but can still log in, or a client asks where their details are kept and nobody has an answer.
Teams that manage their work in a tracker often have the tickets in one place and everything around them spread across comment threads, chat messages and personal notes. Moving that information into its own wiki, on servers you control, answers the question of where your data lives and who can see it before anyone asks.
7 Docmost Features Built for Self-Hosted Project Docs
|
Feature |
What it means for your project docs |
|
Self-hosted deployment |
Docmost runs on your own servers, so your data stays with you |
|
Air-gapped deployment |
Docmost can run on a network with no internet connection |
|
Spaces and roles |
Each project gets its own space, and each person gets Full Access, Can Edit or Viewer |
|
Page-level permissions (paid edition) |
You can limit individual pages to specific people |
|
SSO (paid edition) |
People sign in with the company login they already use, through SAML 2.0, OIDC or LDAP |
|
Version history |
You can see how a page changed and bring back an earlier version |
Project Documentation Needs Its Own Place Outside the Tracker
A tracker is built to follow work while it's happening. It shows who owns a task, what state it's in and when it's due. A closed ticket drops out of sight. The reasoning, steps and client details behind that work are still useful long afterward, so they need a place that's organized by topic instead of by date. That way a decision lives on its own page and not inside an old ticket nobody remembers.
The split usually looks like this:
|
Keep it in the tracker |
Keep it in the wiki |
|
Who owns the task, its status and due date |
The project brief and scope |
|
Back-and-forth on work in progress |
Decisions and the reasoning behind them |
|
Bugs and change requests |
Runbooks and how-to steps |
|
Sprint or milestone plans |
Client notes and meeting outcomes |
A simple rule to follow: if someone will need it after the ticket closes, it belongs on a page.
A project wiki is that place. It works best when the ticket links to the page and the page holds the detail. To plan a project space and its first pages, see this guide on how to set up a project wiki for your team.
Self-Hosting Keeps Project Documentation on Infrastructure You Control
Self-hosting Docmost comes down to three things:
- Your data never leaves infrastructure you control
- You define your own compliance posture (access controls, encryption, retention) instead of inheriting a vendor's
- Hosting, backups, upgrades, and security patching become your IT team's responsibility
Plan for that last point before you install. If your team would prefer not to run servers, Docmost also offers a cloud version.
If you're comparing Docmost with the wiki your tracker's vendor sells, see how Docmost compares with other team wikis. For more on why teams host their own wiki, see this guide to self-hosted wiki software, and for other options, see this roundup of self-hosted documentation tools.
Running It Yourself Means Your IT Team Owns Hosting, Backups and Upgrades
Docker is the recommended way to install Docmost, and a standard setup runs three services: the Docmost app, a PostgreSQL database and Redis. Uploaded files are saved to local storage by default, and you can switch to S3-compatible storage or Azure Blob Storage if you'd like them kept elsewhere. The installation guide walks through the full setup.
Once it's running, your IT team has three jobs:
- Hosting: If you put Docmost behind a reverse proxy to use your own domain and SSL, turn on WebSockets, because the real-time editor needs them.
- Upgrades: Pull the latest image and recreate the container, on whatever schedule suits you.
- Backups: Cover both the database and the file storage, since that's where your content lives.
Spaces, Groups and Roles Let You Limit Each Project's Documentation to Its Team
A space holds a set of pages along with the rules for who can see and edit them, so giving each project its own space keeps its pages with the people working on it. You can add people one at a time or add a whole group, and give each a role. Full Access lets someone manage the space's settings, permissions and pages, Can Edit lets them create and change pages, and Viewer lets them read only. On the paid edition, page-level permissions let you limit individual pages to specific people, and SSO lets everyone sign in with the company login they already use. For more detail, see how spaces work in Docmost.
Adding groups instead of individuals also makes offboarding a single step. When a contractor's work ends, remove them from the group and they lose the access that group gave them.
Once the right people have access, each page still needs someone to keep it accurate. This guide on assigning page owners and review dates shows you how to do both.
Linking Each Ticket to Its Page Keeps Your Documentation Connected
The easiest way to connect a ticket to its documentation is a link, and a few habits keep that connection useful:
- In Docmost: After creating the page, open its three-dot menu and choose Copy link. To link to a specific section, hover over the heading and click the anchor icon.
- In your tracker: Paste that link into the related ticket.
- In Docmost: Near the top of the page, add a "Related tickets" line with the ticket key, so readers can find the work the page is about.
- In Docmost: To link to another page, type @ and choose it from the list.
- When the ticket closes: Add the outcome to the page, including what was decided and what changed, so the reasoning doesn't get buried in a closed ticket.
Add the links as soon as the ticket or page is created, because they're easy to forget later.
Exporting a Space as Markdown or HTML Keeps Your Documentation Portable
You can export a whole space to keep as a backup, move to another tool or read offline. Open Space Settings, go to the Settings tab and click Export. Choose Markdown or HTML, decide whether to include attachments, and Docmost downloads everything to your device as a ZIP file. That way your project documentation stays yours even if you change tools later. The import and export guide has the full steps.
Frequently Asked Questions
- What is a self-hosted wiki for project documentation?
It's a wiki for your project documentation that runs on your own servers instead of a vendor's. With a self-hosted Docmost wiki, the app, the database and the uploaded files all live on servers you control, and your IT team takes care of hosting, backups, upgrades and security patches.
- How do I link a wiki page to a ticket?
Open the page menu and choose Copy link, or copy a heading's anchor link to point at one section, then paste it into the ticket. Adding a "Related tickets" line near the top of the page lets readers get back to the ticket from the page.
- Can I import my existing project documents into Docmost?
Yes. You can import Markdown and HTML files into any space, either one by one or bundled in a ZIP file. Importing Word and PDF files requires the paid edition.
- Can I share a project page with someone outside the team?
Yes. You can share a page through a public link and choose whether to include its subpages and whether search engines can index it. Anyone with the link can see the page, so only share what you're comfortable letting people outside your team see. Turning off public sharing for a whole workspace or space is a paid-edition feature.
- Can I search across my project documentation?
Yes. Full-text search is included in the free open source edition, so people can search their pages for a decision or a runbook instead of browsing the page tree. Searching inside attached PDF and Word files is part of the paid edition.
- What happens if someone deletes a project page by mistake?
Deleted pages move to the space's trash first, where you can restore them or delete them for good. If the problem is an edit and not a deletion, version history lets you restore an earlier version of the page.
Set Up Your Project Wiki on Your Own Servers
Give your project teams one place for their documentation, on servers you control:
- Spaces for organizing project documentation by team or project
- Groups for managing access by team instead of person by person
- Collaborative real-time editor for updating pages together without overwriting each other's work
Docmost includes all of these and more. Contact sales to see how it fits your setup.