Docmost is a self-hosted documentation and knowledge-base application. It provides collaborative editing, organized pages and shared spaces for material such as runbooks, setup notes and team procedures. A useful installation makes information easier to find and maintain while keeping permissions and recovery understandable.

Understand the Application and Its Editions

The official introduction describes collaborative editing and nested pages. Community self-hosting uses the AGPLv3 edition, while commercial editions add features. The edition documentation distinguishes advanced page permissions, SSO and other paid capabilities. Do not assume every feature shown in a current product comparison belongs to the free edition.

Basic workspace and space organization can suit a household or small technical team, but check the exact permission features you require before migrating sensitive documents. A self-hosted application also has running costs: hardware, backups, updates and administrator time. Free software licensing does not guarantee free operation or an included support contract.

Docmost runs alongside PostgreSQL and Redis. Those local dependencies are part of the system you maintain. Avoid describing it as dependency-free, and do not assume that another documentation product necessarily requires a third-party identity provider without checking that product's supported deployment options.

Prepare a Fresh Deployment

This example follows the installation guide and versioned upstream Compose file, using Docmost 0.96.0, PostgreSQL 18 and Redis 8. It is for a new installation with empty named volumes. It is not an in-place upgrade recipe for an existing PostgreSQL 16 installation: database major-version changes require a separate supported migration.

Install Docker Engine and Compose, then create a dedicated project directory. Generate two different random hexadecimal secrets with a password manager or openssl rand -hex 32. Save them as APP_SECRET and POSTGRES_PASSWORD in a protected .env file. Hexadecimal database passwords avoid reserved URL characters in this example's connection string. Otherwise, encode the password correctly for a PostgreSQL URL.

APP_SECRET must meet the documented length requirement and remain stable across normal restarts. Keep it with the recovery materials. Use chmod 600 on the .env file and exclude it from public repositories. Save this as compose.yaml:

services:
  docmost:
    image: docmost/docmost:0.96.0
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    environment:
      APP_URL: http://127.0.0.1:3000
      APP_SECRET: ${APP_SECRET:?Set a long private application secret}
      DATABASE_URL: postgresql://docmost:${POSTGRES_PASSWORD:?Set a hex database password}@db:5432/docmost
      REDIS_URL: redis://redis:6379
    ports:
      - "127.0.0.1:3000:3000"
    restart: unless-stopped
    volumes:
      - docmost_storage:/app/data/storage
  db:
    image: postgres:18
    environment:
      POSTGRES_DB: docmost
      POSTGRES_USER: docmost
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?Set a hex database password}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U docmost -d docmost"]
      interval: 10s
      timeout: 5s
      retries: 10
    restart: unless-stopped
    volumes:
      - db_data:/var/lib/postgresql
  redis:
    image: redis:8
    command: ["redis-server", "--appendonly", "yes", "--maxmemory-policy", "noeviction"]
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 10
    restart: unless-stopped
    volumes:
      - redis_data:/data
volumes:
  docmost_storage:
  db_data:
  redis_data:
docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 docmost

Use authorized Docker access or sudo as required. Health checks wait for dependency readiness during startup; they do not prove that all application functions work or provide automatic recovery from every later failure. Inspect logs if database initialization or application migration fails before trying setup repeatedly.

Complete Onboarding and Verify Access

Open http://127.0.0.1:3000 on the host or through an authenticated SSH tunnel. Create the workspace and owner account on the setup page. Before inviting readers, create a small disposable page and attachment. Confirm that both survive a restart, and test editing from a second browser session if collaboration is important.

The loopback binding provides an initial private test, not a LAN-wide service. For shared access, set APP_URL to the actual browser-facing address and configure the corresponding network route. For remote or untrusted-network access, use HTTPS and follow the reverse-proxy guidance, including support for the application's live connections. Merely changing APP_URL does not create certificates or routing.

Consult the environment reference for email and storage settings. Test an invitation and account-recovery flow using the configured email path. A working owner session can hide a mail configuration error that prevents other users from joining or recovering access.

Check permissions with a separate ordinary member and a logged-out browser. Put a harmless canary document in each intended access scope and verify who can read or edit it. Review any public sharing separately. If a required restriction belongs to a paid edition, resolve that requirement before storing private documentation rather than relying on a permission that is absent.

Build Documentation People Can Use

Create spaces around stable subjects rather than around every short-lived project. Give pages clear titles and identify the system or version a procedure applies to. A runbook should explain its prerequisites, expected result, diagnostic checks and recovery path. Keep real passwords and recovery keys in suitable protected secret storage instead of ordinary shared notes.

For a homelab, a useful first page lists service purpose, owner, access URL, storage location and backup method. A second page can describe a tested restore, including which files and secrets it needs. Link the pages so a reader facing an outage can follow the process without searching through unrelated personal notes.

Assign an owner to important procedures and review them after changes. When a command or interface changes, retain the version context rather than silently blending incompatible instructions. Collaboration helps people update a page; it does not automatically make the information correct or current.

Back Up the Whole System Consistently

The PostgreSQL database and uploaded file storage are both required for a complete recovery. Keep the Compose configuration, protected environment values and edition/license information where applicable. A database-only backup may restore pages while losing attachments; an attachment-only copy loses the organization and application data.

For a small planned backup window, stop application writes, create a database dump using the PostgreSQL backup procedure, and copy the matching file-storage volume. Restart the application after verifying the backup operation. Copying a running database's raw directory with an ordinary file copy is not a substitute for a supported consistent database backup.

Restore into an isolated deployment with compatible versions and preserved secrets. Log in, open representative pages, download attachments and check access with an ordinary member. Record the time and missing dependencies discovered by that exercise. Exported pages are useful for portability, but should not be assumed to preserve every detail of a full application restore.

Plan Updates and Diagnose Failures

Before upgrading, read release notes, retain the current images/configuration and make a consistent backup. Do not run docker compose down -v during routine maintenance: it removes named volumes. Changing database passwords in an environment file also does not automatically rewrite credentials already stored in an initialized database.

If the interface fails, check application, database and Redis logs separately. Verify the intended browser address and proxy behavior before resetting data. After an update, repeat login, editing, attachments, invitations and permission checks. A maintained knowledge base is valuable when both its content and its recovery path continue to work.