To create a self-hosted team knowledge base with Docmost and Docker, deploy the Docmost application with PostgreSQL, Redis, persistent storage, and a configured public URL. This setup gives your team a private workspace for internal documentation, onboarding guides, project notes, runbooks, and company policies.<\/p>
Docmost runs as a Docker container, while PostgreSQL stores workspace data and Redis supports caching and real-time collaboration. Once the containers are running, you can secure the workspace with HTTPS, create team spaces, set permissions, and turn the installation into a structured documentation hub.<\/p>
Before installing Docmost, prepare the following:<\/p>
Docmost runs on Docker<\/a> with three services: the Docmost application, a PostgreSQL database, and Redis. PostgreSQL stores your team’s wiki data, while Redis provides caching and real-time collaboration.<\/p> Before starting, make sure your VPS has Docker and the Docker Compose plugin installed<\/a>. You also need SSH access to your server and a domain or subdomain if you want to access Docmost through a custom URL.<\/p> Connect to your VPS via SSH<\/a> and create a dedicated directory for Docmost:<\/p> This directory will store the Docker Compose<\/a> configuration for the Docmost application, PostgreSQL database, Redis service, and persistent Docker volumes.<\/p> Create a new docker-compose.yml file inside the docmost directory:<\/p> Add the following configuration:<\/p> This file defines all services required to run Docmost. The docmost service starts the application, the db service starts PostgreSQL, and the redis service starts Redis. The three named volumes preserve application files, database records, and Redis data after container restarts.<\/p> Before starting the containers, replace the default values in the Compose file.<\/p> First, update APP_URL with the address users will use to access Docmost. For a basic setup, use your server IP address:<\/p> If you already pointed a domain or subdomain to your VPS, use that URL instead:<\/p> Next, replace APP_SECRET with a secure random string. Generate one with OpenSSL:<\/p> Copy the generated value and add it to the APP_SECRET line:<\/p> Then, replace the PostgreSQL password in both DATABASE_URL and POSTGRES_PASSWORD:<\/p> The PostgreSQL password must be identical in both places. Docmost uses the password in DATABASE_URL to connect to the PostgreSQL container, while PostgreSQL uses POSTGRES_PASSWORD to create the database user.<\/p> Save and close the file. In Nano, press CTRL + X, then Y, then Enter.<\/p> Start the Docmost stack from the same directory as your docker-compose.yml file:<\/p> Docker Compose will download the Docmost, PostgreSQL, and Redis images, create the volumes, and start the containers in the background.<\/p> Check the container status:<\/p> All three services should appear as running. If one service exits or keeps restarting, check the logs:<\/p> To view only the Docmost application logs, run:<\/p> The logs help identify common configuration issues, such as an invalid APP_SECRET, mismatched database password, or unavailable Redis service.<\/p> After the containers are running, open Docmost using your server IP and port 3000:<\/p> If you configured a domain in APP_URL, open that domain instead:<\/p> Docmost will display the initial setup screen. Create the first admin account and workspace. This admin account manages users, team spaces, permissions, and documentation settings.<\/p> You can also verify the application with the health check endpoint:<\/p> A successful health check confirms that the Docmost application is responding.<\/p> If Docmost does not load in the browser, the server firewall may be blocking port 3000.<\/p> On servers using UFW, allow TCP traffic on port 3000:<\/p> Then, open Docmost again:<\/p> This setup is enough for initial testing. For production use, place Docmost behind a reverse proxy with SSL, so your team can access the knowledge base through a secure domain such as https:\/\/docs.example.com.<\/p> A Docmost knowledge base can contain internal policies, onboarding documents, project plans, and technical documentation. Secure the application before inviting teammates so that only authorized users can access, edit, and manage your workspace.<\/p> For general server protection, follow our <\/a>VPS security best practices<\/a>, which cover SSH keys, firewall configuration, root login protection, strong passwords, malware scanning, and server monitoring. This section focuses only on Docmost-specific security steps for a team documentation setup. Hostinger’s VPS security guide recommends monitoring SSH access, root permissions, passwords, firewalls, user privileges, and server logs as part of regular VPS protection.<\/p> Run Docmost behind a domain or subdomain instead of sharing the raw server IP with your team. A domain like docs.example.com is easier to manage, works better with SSL certificates<\/a>, and keeps the workspace URL consistent if you move the application later.<\/p> After pointing the domain to your VPS<\/a>, update the APP_URL value in your docker-compose.yml file:<\/p> Then restart the Docmost container:<\/p> Use HTTPS for production workspaces. SSL encrypts the connection between Docmost and your team members, which helps protect login sessions, page content, and account data during transmission.<\/p> A reverse proxy<\/a> lets users access Docmost through ports 80 and 443 instead of opening port 3000 publicly. It also handles SSL certificates and routes traffic from your domain to the Docmost container.<\/p> For a production setup, configure Nginx, Caddy, or another reverse proxy to forward requests from your domain to:<\/p> After the reverse proxy is working, limit public access to port 3000. On servers using UFW, remove the public rule for port 3000 and allow only HTTP, HTTPS, and SSH:<\/p> This keeps Docmost accessible through the secure domain while reducing unnecessary open ports on the VPS.<\/p> Docmost uses real-time collaboration features, so the reverse proxy must support WebSocket connections. Without WebSocket forwarding, pages may load correctly, but live editing and collaboration features may not work as expected.<\/p> For Nginx, include the WebSocket headers in the Docmost server block:<\/p> After updating the reverse proxy configuration, reload Nginx:<\/p> Then test Docmost by opening the workspace in two browser windows and editing the same page from both sessions.<\/p> Docmost relies on APP_SECRET and the PostgreSQL password to secure the application and database connection. These values should be unique, long, and different from other server or account passwords.<\/p> Your Compose file should not keep placeholder values like these:<\/p> Use generated values instead:<\/p> Generate a new app secret with:<\/p> Do not change APP_SECRET after users start using the workspace unless you are prepared to invalidate existing sessions. For team environments, store credentials in a secure password manager and limit access to the VPS and Compose file.<\/p> Docmost security also depends on workspace structure. Create separate spaces for teams, departments, or projects instead of storing every document in one shared area.<\/p> For example, you can create spaces for:<\/p> Assign users to groups based on their role. Give edit access only to team members who maintain the documentation, and use view-only access for readers who only need to reference pages.<\/p> This structure prevents accidental edits and keeps sensitive documentation, such as HR policies or infrastructure notes, visible only to the right users.<\/p> Docmost stores important workspace data in Docker volumes. Back up the PostgreSQL volume and application data volume regularly so you can restore your knowledge base after accidental deletion, server failure, or a broken update.<\/p> At minimum, back up these volumes from the Docker Compose setup:<\/p> The PostgreSQL volume is the most important because it stores the main workspace records. The application data volume can include uploaded files and other persistent Docmost data.<\/p> Before updating or changing the setup, create a fresh backup. This is especially important for team wikis because documentation changes often happen daily.<\/p> Keep the Docmost image up to date to receive application improvements and security fixes. To update the Docmost container, pull the latest image and recreate the application service:<\/p> After the update, check the container status:<\/p> Then open Docmost and confirm that users, spaces, and pages load correctly.<\/p> Do not update production workspaces without a backup. A backup gives you a restore point if the new container version causes compatibility or startup issues.<\/p> After installing Docmost, organize the workspace around how your team searches for information. A good team wiki should make recurring knowledge easy to find, update, and reuse across departments.<\/p> Start by creating spaces for the main documentation areas your team uses every day. For example, create separate spaces for the company handbook, employee onboarding, engineering documentation, product notes, customer support playbooks, and internal operations.<\/p> Each space should have a clear purpose. The Engineering space can store architecture notes, deployment steps, incident response guides, and runbooks. The Employee onboarding space can include first-week tasks, instructions for accessing tools, team introductions, and role-specific checklists.<\/p> Spaces are the main containers for organizing documentation in Docmost. Use them to separate broad knowledge areas rather than storing every page in a single shared workspace.<\/p> For a small team, create spaces by function:<\/p> For a larger organization, create spaces by department, project, or access level:<\/p> Use clear space names that match how your team describes its work. Avoid vague labels like General, Misc, or Docs, because they make the wiki harder to navigate as the number of pages grows.<\/p> A new knowledge base works best when it already contains useful starting points. Before inviting the whole team, add the pages people will need first.<\/p> Start with these core pages:<\/p> Each page should answer one clear question. For example, create a page called How to request production access instead of placing access instructions inside a long onboarding document. This makes the page easier to search, share, and update.<\/p> Nested pages help turn broad topics into structured documentation paths. Use a parent page for the main topic, then add child pages for specific procedures or references.<\/p> For example, an Engineering space can use this structure:<\/p> This structure helps users move from general context to specific instructions. It also prevents long pages from becoming difficult to scan.<\/p> Every important page should have an owner. Page ownership helps teams keep documentation accurate after processes, tools, or responsibilities change.<\/p> Add the owner near the top of each page:<\/p> For critical documentation, such as deployment steps or incident response procedures, assign ownership to a team rather than one person. Team ownership reduces the risk of outdated documentation when someone changes roles or leaves the company.<\/p> Use a review cycle for pages that affect daily operations. For example, onboarding pages can be reviewed every quarter, while deployment runbooks should be reviewed after major infrastructure changes.<\/p> Docmost permissions should match the sensitivity of each documentation area. Give edit access to people responsible for maintaining the content, and give view access to people who only need to read it.<\/p> For example, HR can edit the company handbook while all employees can view it. Engineering leads can edit deployment runbooks, while the wider technical team can use them as references. Leadership notes should stay limited to the people who need access.<\/p> This setup keeps documentation open enough to be useful while reducing accidental edits in important spaces.<\/p> Docmost supports collaborative editing, which is useful when several team members need to build or update the same page. Use real-time editing for planning documents, meeting notes, incident reports, and process updates.<\/p> Good use cases include writing release notes during a product launch, updating an incident report during an outage, creating onboarding documentation with input from multiple departments, and reviewing a new internal process with team leads.<\/p> After a collaborative session, clean up the page before treating it as official documentation. Remove temporary notes, assign an owner, add a review date, and link the page from the right parent page or space.<\/p> Visual documentation helps teams understand workflows faster than text-only pages. Use diagrams in Docmost to explain systems, handoffs, decision paths, and internal processes.<\/p> For example, add diagrams for application architecture, deployment flow, customer escalation, employee onboarding, incident response, or approval workflows.<\/p> Place the diagram near the top of the page, then explain each step below it. This gives readers a quick overview first and detailed instructions afterward.<\/p> Templates keep documentation consistent across the team. Instead of writing every page from scratch, create reusable formats for common page types.<\/p> Useful team wiki templates include:<\/p> For example, an incident report template can include:<\/p> A consistent template helps readers know where to find the same type of information on every page. It also makes new documentation easier to create because writers do not need to decide the structure each time.<\/p> A team knowledge base becomes less useful when old pages, duplicate instructions, and unclear ownership start to pile up. Keep Docmost maintainable by reviewing the workspace regularly.<\/p> Archive pages that are no longer relevant, merge duplicate pages that explain the same process, and add owners and review dates to operational documents. Link related pages together so users can move between connected topics.<\/p> Keep page titles specific and action-based. For example, use How to deploy the API instead of API notes. The first title tells readers exactly what the page helps them do, while the second title is too broad to be useful in search results.<\/p> A well-maintained Docmost workspace becomes the source of truth for team knowledge. New employees can onboard faster, existing team members can find answers without asking in chat, and process owners can keep critical documentation updated in one place.<\/p> Manual Docker Compose installation gives you full control over the Docmost setup. Hostinger’s Docker catalog<\/a> is faster because it deploys Docmost from a preconfigured application catalog, rather than requiring you to create a Compose file, install dependencies, and start each service manually.<\/p> Use this option if you want to launch a team wiki quickly and manage it from a VPS control panel. Hostinger’s Docmost template includes a preconfigured setup for the application, while the VPS plans include Docker manager, container logs, one-click updates, and automatic weekly backups.<\/p> To deploy Docmost with Hostinger’s Docker template:<\/p> After deployment, use the admin account to create spaces, invite users, and set permissions for each team. For example, create separate spaces for Engineering, Product, Support, and HR rather than storing all internal documentation in a single shared area.<\/p> Hostinger’s template is especially useful if you want to avoid manual Docker configuration. The catalog page positions the template as a one-click Docmost installation with no manual setup, while the built-in Docker manager helps you deploy, update, and monitor containers from one place.<\/p> You can still apply the same production steps after using the template. Point a domain or subdomain to the VPS, use HTTPS, review access permissions, and set a backup routine before making the knowledge base the source of truth for your team.<\/p> After Docmost is running, turn the empty workspace into a reliable source of truth for your team. Start with the documentation that people request most often, such as onboarding steps, access instructions, deployment processes, internal policies, and support workflows.<\/p> Create a simple structure first. Add a space for each main team or documentation area, then create a few high-value pages within each space. For example, an Engineering space can start with deployment steps and incident response notes, while an HR space can start with onboarding, benefits, and company policy pages.<\/p> Before inviting the whole team, define how documentation should be created and maintained. Add a short Documentation rules page that explains how to name pages, when to use templates, who owns each space, and how often important pages should be reviewed. This prevents the wiki from becoming a collection of outdated notes.<\/p> Next, assign owners to critical pages. Deployment runbooks, onboarding checklists, policy documents, and support playbooks should have a clear owner and review date. A simple ownership note is enough:<\/p> Once the structure is ready, invite users and set permissions. Give edit access to people who maintain the documentation, and give view access to people who only need to read it. This keeps the knowledge base useful without making sensitive or operational pages easy to change by accident.<\/p> Finally, treat Docmost like part of your team’s infrastructure. Keep the Docker containers updated, back up the application and database volumes, and review access regularly. If you deployed Docmost manually, document the setup process inside Docmost itself so future administrators can maintain or restore the workspace more easily.<\/p>\n","protected":false},"excerpt":{"rendered":" To create a self-hosted team knowledge base with Docmost and Docker, deploy the Docmost application with PostgreSQL, Redis, persistent storage, […]<\/p>\n1. Create a Docmost project directory<\/h3>
mkdir docmost\ncd docmost<\/pre>
2. Create the Docker Compose file<\/h3>
nano docker-compose.yml<\/pre>
services:\ndocmost:\nimage: docmost\/docmost:latest\ndepends_on:\n- db\n- redis\nenvironment:\nAPP_URL: \"http:\/\/your-server-ip:3000\"\nAPP_SECRET: \"replace-this-with-a-secure-random-string\"\nDATABASE_URL: \"postgresql:\/\/docmost:replace-this-password@db:5432\/docmost?schema=public\"\nREDIS_URL: \"redis:\/\/redis:6379\"\nports:\n- \"3000:3000\"\nvolumes:\n- docmost_data:\/app\/data\nrestart: unless-stopped\ndb:\nimage: postgres:16-alpine\nenvironment:\nPOSTGRES_DB: docmost\nPOSTGRES_USER: docmost\nPOSTGRES_PASSWORD: \"replace-this-password\"\nvolumes:\n- db_data:\/var\/lib\/postgresql\/data\nrestart: unless-stopped\nredis:\nimage: redis:7.2-alpine\nvolumes:\n- redis_data:\/data\nrestart: unless-stopped\nvolumes:\ndocmost_data:\ndb_data:\nredis_data:<\/pre>
3. Replace the placeholder values<\/h3>
APP_URL: \"http:\/\/your-server-ip:3000\"<\/pre>
APP_URL: \"https:\/\/docs.example.com\"<\/pre>
openssl rand -hex 32<\/pre>
APP_SECRET: \"your-generated-secret\"<\/pre>
DATABASE_URL: \"postgresql:\/\/docmost:your-secure-password@db:5432\/docmost?schema=public\"\nPOSTGRES_PASSWORD: \"your-secure-password\"<\/pre>
4. Start Docmost with Docker Compose<\/h3>
docker compose up -d<\/pre>
docker compose ps<\/pre>
docker compose logs<\/pre>
docker compose logs docmost<\/pre>
5. Open Docmost in your browser<\/h3>
http:\/\/your-server-ip:3000<\/pre>
https:\/\/docs.example.com<\/pre>
http:\/\/your-server-ip:3000\/api\/health<\/pre>
6. Allow access to port 3000<\/h3>
sudo ufw allow 3000\/tcp\nsudo ufw reload<\/pre>
http:\/\/your-server-ip:3000<\/pre>
How to secure Docmost for team use<\/h2>
1. Use a domain with HTTPS<\/h3>
APP_URL: \"https:\/\/docs.example.com\"<\/pre>
docker compose up -d<\/pre>
2. Put Docmost behind a reverse proxy<\/h3>
http:\/\/127.0.0.1:3000<\/pre>
sudo ufw delete allow 3000\/tcp\nsudo ufw allow OpenSSH\nsudo ufw allow 80\/tcp\nsudo ufw allow 443\/tcp\nsudo ufw reload<\/pre>
3. Enable WebSocket support<\/h3>
proxy_http_version 1.1;\nproxy_set_header Upgrade $http_upgrade;\nproxy_set_header Connection \"upgrade\";\nproxy_set_header Host $host;\nproxy_set_header X-Real-IP $remote_addr;\nproxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\nproxy_set_header X-Forwarded-Proto $scheme;<\/pre>
sudo systemctl reload nginx<\/pre>
4. Keep secrets and passwords unique<\/h3>
APP_SECRET: \"replace-this-with-a-secure-random-string\"\nPOSTGRES_PASSWORD: \"replace-this-password\"<\/pre>
APP_SECRET: \"your-generated-app-secret\"\nPOSTGRES_PASSWORD: \"your-secure-database-password\"<\/pre>
openssl rand -hex 32<\/pre>
5. Configure team spaces and permissions<\/h3>
\n
6. Back up Docmost data<\/h3>
docmost_data\ndb_data\nredis_data<\/pre>
7. Update Docmost regularly<\/h3>
docker pull docmost\/docmost:latest\ndocker compose up --force-recreate --build docmost -d<\/pre>
docker compose ps<\/pre>
How to use Docmost as a team wiki and documentation hub<\/h2>
Create spaces for teams, projects, or departments<\/h3>
Engineering\nProduct\nSupport\nHR and onboarding\nCompany handbook<\/pre>
Infrastructure\nFrontend\nBackend\nInternal policies\nLeadership notes\nCustomer operations<\/pre>
Add core pages before inviting the team<\/h3>
\n
Use nested pages for step-by-step documentation<\/h3>
Engineering\n├── Architecture overview\n├── Deployment process\n│ ├── Deploying the frontend\n│ ├── Deploying the backend\n│ └── Rolling back a release\n├── Incident response\n│ ├── Severity levels\n│ ├── On-call checklist\n│ └── Postmortem template\n└── Development environment\n├── Local setup\n├── Environment variables\n└── Testing commands<\/pre>
Assign ownership to important pages<\/h3>
Owner: Engineering team\nLast reviewed: 2026-05-18\nReview cycle: Every 3 months<\/pre>
Set permissions based on how each team uses the wiki<\/h3>
Use real-time editing for collaborative documentation<\/h3>
Use diagrams to explain processes and systems<\/h3>
Create templates for repeatable documentation<\/h3>
Meeting notes\nIncident report\nProject brief\nRunbook\nHow-to guide\nRelease notes\nDecision record\nOnboarding checklist<\/pre>
Title:\nDate:\nIncident owner:\nImpact:\nTimeline:\nRoot cause:\nResolution:\nFollow-up actions:<\/pre>
Keep the team wiki easy to maintain<\/h3>
How to deploy Docmost faster with Hostinger’s Docker template<\/h2>
\n
Next steps for your self-hosted team knowledge base<\/h2>
Owner: Engineering team\nLast reviewed: 2026-05-18\nReview cycle: Every 3 months<\/pre>