nobbe/ignis repository overview

⁠Ignis Server

The self-hosted Docker variant of Ignis. For the project overview, feature list, and what works / what doesn't, see the root README⁠.

⁠Contents

• Authentication⁠
• Secure context (HTTPS)⁠
• Setup with Docker Compose⁠
• Volumes⁠
• Environment Variables⁠
• Migrating an existing vault⁠
• Upgrading Obsidian⁠
• Backups⁠

⁠Authentication

Ignis has no built-in authentication and serves plain HTTP by default. Both authentication and TLS termination are expected to be handled by whatever you put in front of it.

If you are exposing Ignis to the internet, you should really put an authentication layer in front of it. Options include:

• A reverse proxy with Basic Auth (nginx, Caddy, Traefik)
• An SSO proxy like Authelia, Authentik, or OAuth2 Proxy
• A VPN (Tailscale, WireGuard)
• Cloudflare Application Tunnel

Example configurations for Basic Auth and Authelia are in examples/⁠.

Ignis also runs a cross-origin proxy (/api/proxy) that reaches any public host by default. It rejects private, loopback, and link-local addresses, and you can narrow it to an allowlist or disable it entirely from the proxy settings in the Ignis settings panel. A companion direct-fetch host list (same Settings > Security panel) marks hosts the browser fetches directly instead of through the proxy, for CORS-friendly hosts.

⁠Secure context (HTTPS)

Browsers only expose the crypto and clipboard APIs Obsidian relies on in a secure context⁠. Served over plain HTTP at a non-localhost origin (a LAN IP or a bare domain), Ignis loses graph view, backlinks, the outline, some clipboard operations, and Sync, and shows a warning banner. http://localhost and http://127.0.0.1 are treated as secure, so a purely local instance is unaffected.

Three ways to get a secure context:

• A TLS reverse proxy. Caddy, nginx, Traefik, or any of the examples/⁠ configs. For anything internet-facing.
• tailscale serve. Puts HTTPS in front of Ignis on a tailnet with no certificate management. For private remote access.
• Mark the origin trusted in the browser. The most direct fix for LAN access without TLS: tell the browser to treat the Ignis origin as a secure context. No server changes, but per-browser and per-machine, so every client has to set it.
  • Chromium (Chrome, Edge, Brave, Opera, Vivaldi): open chrome://flags/#unsafely-treat-insecure-origin-as-secure (Edge and Brave expose the same flag at edge://flags and brave://flags), set it to Enabled, enter the Ignis origin in the box (for example http://192.168.1.10:8080; comma-separate several), and relaunch the browser.
  • Firefox: in about:config, add the host to dom.securecontext.allowlist (comma-separated). Firefox may then try to upgrade sub-resource requests to HTTPS, which can break asset loading, so a reverse proxy is the more reliable option here.
  • Safari: no equivalent flag, safari requires TLS.

⁠Setup with Docker Compose

Example docker-compose.yml:

services:
  ignis:
    image: nobbe/ignis:latest
    ports:
      - "8080:8080"
    environment:
      - OBSIDIAN_VERSION=1.12.7
      - PUID=1000
      - PGID=1000
    volumes:
      - ./vaults:/vaults
      - ./data:/app/data
      - obsidian-app:/app/obsidian-app
    restart: unless-stopped

volumes:
  obsidian-app:

Then docker compose up -d. On first start the container downloads Obsidian from the official source and installs the Obsidian Headless CLI. This takes a minute or two.

To build from source instead of pulling the image, clone the repo and run docker compose up against the docker-compose.yml⁠ in this directory.

⁠Volumes

⁠Ownership on NFS shares

For NFS shares with root_squash, set the share's owner to PUID/PGID or export the share with no_root_squash, so that PUID/PGID can read and write /vaults, /app/data, and /app/obsidian-app. The container chowns these paths to PUID/PGID at startup, which root_squash blocks. When the chown fails, the container still runs, and file access falls to the mount's own permissions, so Ignis works only where PUID/PGID can already read and write.

⁠Environment Variables

Demo mode adds its own set of env vars (per-session vaults, auto-cleanup, proxy allowlist, login blocking). See examples/demo/⁠ if you want to run a public demo deployment.

⁠Offline / restricted-network install

If the container can't reach GitHub on first run (air-gapped or restricted networks), download Obsidian yourself from obsidian.md⁠ (the .deb), mount it into the container, and point OBSIDIAN_PACKAGE at it:

    volumes:
      - ./obsidian_1.12.7_amd64.deb:/packages/obsidian.deb:ro
    environment:
      - OBSIDIAN_PACKAGE=/packages/obsidian.deb

On first run the entrypoint unpacks that instead of downloading. Match the version this release pins (see the OCI label and CHANGELOG); a mismatch logs a warning and still boots. .asar.gz and .asar are also accepted.

⁠Migrating an existing vault

Each subdirectory of /vaults is treated as a separate vault, so dropping in an existing Obsidian vault directory will make it available in Ignis.

⁠Upgrading Obsidian

Obsidian releases can include changes that break the compatibility shim. Each Ignis release pins a known-working Obsidian version through the OBSIDIAN_VERSION env var, so the recommended path is to wait for an Ignis release that bumps the version, pull the new image, and restart.

If you want to try a newer Obsidian version before Ignis updates, set OBSIDIAN_VERSION in your compose file. The entrypoint will download that version on next start, but there is no guarantee it will work cleanly with the current shim.

⁠Backups

Vault data lives as ordinary files in /vaults. Back it up however you back up other server-side data; Ignis does not provide a built-in backup mechanism.