Run Outline Wiki on a VPS With Docker and TLS

Notion and Confluence work well—until they become a compliance headache, feel slow from your region, or jump in price at renewal. If you want a modern internal knowledge base you control end to end, Outline is a solid option.

This post covers what Outline is, who it fits, and how to run Outline on a VPS with Docker Compose, HTTPS, backups, and predictable upgrades.

This stays close to real ops work. You’ll see ports, DNS, reverse-proxy headers, storage growth, and what you actually need to back up.

The goal is simple: restores shouldn’t be a guessing game.

Outline in one sentence: a team wiki that stays snappy

Outline is an open-source team wiki built for fast navigation, clean writing, and structured collections. You can self-host it, connect it to your identity provider, and keep documents and attachments on storage you manage.

License note: Outline is published as open-source (check the project repository for the exact license and any enterprise add-ons). Before you deploy it in production, confirm the terms for your use case.

This matters most if you plan to resell hosted access or bundle it into a service.

Who Outline is for (and who should skip it)

Outline fits teams that run services and need operational knowledge in one place. It keeps docs out of chat scrollback and off scattered personal notes.

• Small teams that want a wiki with strong search and quick editing.
• Agencies maintaining client runbooks, onboarding steps, and incident notes.
• SaaS operators who prefer internal docs near the rest of the stack (monitoring, CI, secrets).
• Security-conscious orgs that can’t put internal knowledge in third-party SaaS.

Pick something else if your primary need is “notes + tasks + databases.” Outline is documentation-first.

It won’t replace a project manager or a spreadsheet-heavy workspace.

Outline vs Notion and Confluence: the practical differences

If you’re coming from a hosted tool, don’t ask “does Outline do everything?” Ask “does it fix the pain I’m dealing with?”

Here’s the operator’s view.

• Data control: With Outline on your own server, you decide how backups run, how long you retain them, and who can reach the system. Notion/Confluence offer exports, but you still rely on their platform availability and account rules.
• Latency and reliability: During an incident, a wiki has to load now. Hosting Outline near your apps (or your team) cuts down the “it’s slow right now” problem.
• Authentication: Confluence shines if you’re already all-in on Atlassian. Outline gives you options, but you’ll need to wire SSO/OAuth carefully and keep it tight.
• Cost curve: Hosted tools usually scale by seat. Self-hosting shifts cost to infrastructure plus your admin time. For steady teams, a small VPS often stays cheaper and more predictable.

The trade-off is straightforward. Self-hosting buys control and performance, but you own patching, backups, and uptime.

If you can’t take that on, stick with managed SaaS.

What you need to run Outline on a VPS (sizing and dependencies)

Outline isn’t a single binary you drop onto a server. A typical self-hosted setup has a few moving parts:

• Outline app container
• PostgreSQL for persistent data
• Redis for caching/queues
• Object storage for file uploads (either S3-compatible, or a local disk volume depending on how you configure uploads)
• Reverse proxy (Nginx or Caddy) for HTTPS and correct headers

Baseline VPS sizing for 2026:

• Small team (up to ~20 active users): 2 vCPU, 4 GB RAM, 60+ GB NVMe
• Medium team (20–100 active users): 4 vCPU, 8 GB RAM, 100+ GB NVMe
• Heavier usage / many attachments: prioritize storage and backups (and consider dedicated object storage)

At this scale, Postgres and Redis are rarely the bottleneck. Attachments and document history tend to creep up over time.

Plan storage early. It’s much easier than scrambling later.

If you want a predictable platform for long-running internal apps, start with a HostMyCode VPS.

If you don’t want to own OS updates, Docker maintenance, and security patching, managed VPS hosting is the safer choice for a business-critical wiki.

A sane deployment model: Docker Compose + reverse proxy

Docker Compose keeps the app and its dependencies consistent across upgrades. You define services, persist what needs persistence, and restart the stack as a unit.

Your reverse proxy terminates TLS and routes traffic to the Outline container on a private Docker network.

Two patterns tend to work best:

• Nginx on the host (common on VPS setups, flexible when you run multiple apps)
• Caddy for automatic Let’s Encrypt (useful if you want fewer manual TLS steps)

If you already use Caddy for other containers, HostMyCode has a practical guide you can follow: set up Caddy reverse proxy for Docker on a VPS.

Deploy Outline with Docker Compose (example you can adapt)

This isn’t a full “paste this and walk away” tutorial. It’s a realistic Compose layout so you can see how the pieces fit.

Use it as a starting point. Then align the environment variables and auth settings with Outline’s official docs.

Recommended host OS: Ubuntu 24.04 LTS or Debian 12, kept patched.

Install Docker Engine and the Compose plugin from upstream packages (not snap) to avoid odd packaging edge cases.

# /opt/outline/docker-compose.yml
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: outline
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: outline
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    command: ["redis-server", "--appendonly", "yes"]
    volumes:
      - ./data/redis:/data
    restart: unless-stopped

  outline:
    image: outlinewiki/outline:latest
    environment:
      # App basics
      URL: https://wiki.example.com
      PORT: 3000
      
      # Database
      DATABASE_URL: postgres://outline:change-me@postgres:5432/outline

      # Redis
      REDIS_URL: redis://redis:6379

      # Security
      SECRET_KEY: "generate-a-long-random-string"
      UTILS_SECRET: "generate-another-long-random-string"

      # File storage/auth settings are intentionally omitted here.
      # Configure them based on your chosen provider (S3-compatible, local, etc.).

    depends_on:
      - postgres
      - redis
    restart: unless-stopped

networks:
  default:
    name: outline_net

Operational notes that matter:

• Keep Postgres and Redis on the private Docker network. Only the reverse proxy should be reachable from the internet.
• Generate secrets with openssl rand -hex 32 (or longer). Don’t reuse secrets across services.
• Use stable images where possible. Pin tags (for example, Postgres 16) so upgrades happen on purpose.

Reverse proxy + HTTPS: Nginx example with the right headers

Outline relies on proxy headers to build absolute URLs and set secure cookies correctly. If Nginx terminates TLS, pass X-Forwarded-Proto and X-Forwarded-For.

Also include WebSocket upgrade headers.

Example Nginx server block:

# /etc/nginx/sites-available/wiki.example.com
server {
  listen 80;
  server_name wiki.example.com;

  location /.well-known/acme-challenge/ {
    root /var/www/letsencrypt;
  }

  location / {
    return 301 https://$host$request_uri;
  }
}

server {
  listen 443 ssl http2;
  server_name wiki.example.com;

  ssl_certificate /etc/letsencrypt/live/wiki.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/wiki.example.com/privkey.pem;

  # Basic hardening
  add_header X-Content-Type-Options nosniff always;
  add_header X-Frame-Options SAMEORIGIN always;
  add_header Referrer-Policy strict-origin-when-cross-origin always;

  client_max_body_size 50m;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

proxy_pass points to 127.0.0.1:3000. That means you either publish the container port to localhost only, or run Nginx in Docker on the same network.

Both are fine.

The main rule: don’t bind app ports to 0.0.0.0 unless you truly intend to expose them.

If uploads start failing behind Nginx, you’ll usually see a 413. HostMyCode has a straightforward fix guide: Nginx 413 Request Entity Too Large fix on a VPS.

DNS and certificates: don’t skip the boring parts

Use a dedicated hostname like wiki.example.com and point A/AAAA records at your server.

If you manage multiple environments or client stacks, treat this as standard practice. Use one service per subdomain, with clear routing.

If you need to register or transfer a domain, use HostMyCode Domains so DNS and billing live in one place.

For TLS, Let’s Encrypt remains the default choice in 2026.

If you prefer Caddy’s automated certificate management, the HostMyCode walkthrough is a good reference: set up Let’s Encrypt with Caddy.

Backups that actually let you restore

Outline backups come down to two things: the PostgreSQL database and whatever holds your uploads/attachments.

Back up only the DB and you’ll restore pages but lose files. Back up only uploads and you’ll end up with blobs that don’t match your content.

Minimum backup set:

• PostgreSQL dump (consistent, restorable) or physical backups if you know what you’re doing
• Uploads bucket (S3-compatible) or the local uploads volume
• Compose files and env (minus secrets if you store them elsewhere), so rebuild is straightforward

Practical approach for small deployments:

• Nightly pg_dump to a backup directory
• Daily sync of that directory to offsite storage (another server, object storage, or backup provider)
• Weekly restore test to a temporary VM

Example dump command you can run from the host (assuming the DB is in a container named postgres):

# Create backup directory
mkdir -p /var/backups/outline

# Dump DB (use a dedicated DB password, not your day-to-day shell history)
docker exec -t postgres pg_dump -U outline outline \
  | gzip > /var/backups/outline/outline-$(date +%F).sql.gz

Keep 7–30 days of daily dumps, based on how often the wiki changes.

The disk you spend here is cheaper than recreating lost runbooks from memory.

If you want a broader backup strategy for a VPS stack, the process in create secure backups on Ubuntu is worth skimming even if you’re using Postgres; the retention and verification habits translate cleanly.

Updates: how to upgrade without breaking Monday morning

Container upgrades are usually simple, but they still deserve a routine.

Read the release notes, take a backup, then roll forward with a rollback plan you’ve already thought through.

• Pin images (at least for Postgres/Redis). Upgrades should be deliberate.
• Back up first (DB + uploads). No exceptions.
• Pull, then restart with Compose, and watch logs for migrations.

cd /opt/outline

docker compose pull

docker compose up -d

docker compose logs -f --tail=200 outline

Rollback reality: Rolling back an app container is easy. Rolling back a database after a migration usually isn’t.

That’s why a tested restore beats confidence every time.

If you want fewer “we forgot to patch the host” moments, enable unattended security updates. HostMyCode keeps a current guide here: automated security updates on Ubuntu VPS.

Common pitfalls operators hit in the first week

• Wrong external URL: If URL doesn’t match the real HTTPS URL, expect weird redirects and cookie problems.
• Uploads stored on the root disk: Small VPS disks fill faster than people expect. Track attachment growth and alert on free space.
• Exposed database ports: Postgres and Redis should not be reachable from the public internet. Keep them on internal networks.
• Oversized logs: Container logs can balloon. Set Docker log rotation or ship logs somewhere sensible.
• No restore plan: “We have backups” isn’t a plan. Do one restore to a staging VM and write down the steps in the wiki itself.

Where Outline fits in a real hosting stack

A wiki pays off most when you treat it like production software: monitored, backed up, and documented.

Plug it into the way you already run services.

• Status checks: Monitor the login page and an API endpoint in your uptime tool. If you already run Uptime Kuma, reuse your pattern from Self-host Uptime Kuma on a VPS.
• Incident playbooks: Keep rollback and restore procedures short, specific, and tested.
• Access control: Set up SSO/OAuth early. Shared local admin accounts age badly.

Eventually the wiki stops being “just documentation” and starts behaving like infrastructure.

Plan and operate it that way.

FAQ

Do I need a dedicated server to run Outline?

No. Most teams can run Outline comfortably on a VPS. Move to a dedicated server if you’re hosting many services on the same box, or if attachments and I/O demands grow.

What should I back up for an Outline restore?

Back up PostgreSQL (the wiki content, users, settings) and your uploads/attachments storage. Without both, restores will be incomplete.

Can I host Outline behind Cloudflare?

Yes, but still keep end-to-end HTTPS correct. Make sure the app sees the right X-Forwarded-Proto header and that your URL matches the public hostname.

Is Docker Compose the best way to deploy Outline?

For most VPS operators, yes. It’s repeatable, upgrade-friendly, and easy to back up. If you already standardize on systemd services and native packages, you can still run containers with a host-level reverse proxy.

Summary: keep your team knowledge fast, private, and recoverable

Outline works well as a replacement for SaaS knowledge bases when you want speed, control, and reliable access during real incidents.

The difference between “we deployed it” and “we can trust it” is basics done consistently: private networking, correct proxy headers, HTTPS, tested backups, and cautious upgrades.

If you want to run Outline on a VPS without turning it into a science project, build on a stable base like a HostMyCode VPS.

Operate the wiki like any other production service: monitor it, patch it, and back it up.