Ignis: Self-Hosted Obsidian in a Browser

Why Ignis Exists for Obsidian Users

Ignis addresses a specific remote-access problem. Obsidian is designed around a local installation and a local vault, while many existing remote arrangements rely on VNC or a similar remote desktop. Ignis instead presents Obsidian through a browser interface backed by a server. The README calls this an actual web app, rather than a remote desktop session.

The intended users are people who want to reach their own Obsidian installation from a browser while keeping the vault on the server. That can suit a home server, a private network, or a carefully protected internet-facing deployment. It is not a replacement for every Obsidian workflow. The project is explicitly a compatibility shim, not a fork that includes Obsidian itself. The Docker container downloads Obsidian from its official source on first run.

The distinction matters for evaluation. Ignis is not merely a static note viewer. The README lists the editor, canvas, bases, command palette, context menus, themes, CSS snippets, file upload and download, multi-vault management, saved workspaces, direct note URLs, and a mobile UI. Those features describe a browser client whose state is tied to server-side vault files and browser-side tabs.

How Ignis Connects Browser APIs to Obsidian

Ignis implements browser-compatible versions of the Electron APIs that Obsidian uses. Those implementations form a shim layer between the browser and the Obsidian application. The repository places the server in `apps/ignis-server/` and the shim, UI, and shared libraries in `packages/`, which matches the monorepo description in `package.json`.

The server keeps the vault on its filesystem. The README documents separate mount points for vault content and application data, plus a Docker volume for `obsidian-app`. Browser requests can therefore operate against files that remain outside the browser's local storage. The documentation also describes a cross-origin proxy for plugin requests and a direct-fetch allowlist for CORS-friendly hosts. That arrangement is relevant for plugins whose requests are not designed for an ordinary browser security model.

Ignis uses WebSockets for live synchronization between tabs. The README says edits propagate within a second. It also describes a pre-compressed bootstrap response containing vault information, the vault list, metadata, and the plugin list in one call. A live file-event mechanism keeps the file tree current. These choices indicate that Ignis is not simply sending an entire vault to every browser on each action. It also uses an indexer pre-fetch and an LRU content cache, documented with a default limit of 50 MB.

The important boundary is that the shim can reproduce an API only when a browser equivalent exists. Ignis cannot turn browser JavaScript into a full Electron runtime. That is the source of its plugin and feature limitations.

Docker Compose Installation and First Vault

The README provides a basic Docker Compose deployment. Save the following as `docker-compose.yml`. The service publishes port 8080, maps host directories for vaults and application data, creates a named volume for the downloaded Obsidian application, and restarts unless stopped.

services:
  ignis:
    image: nobbe/ignis:latest
    ports:
      - "8080:8080"
    environment:
      # match these to your host user (run: id)
      - PUID=1000
      - PGID=1000
    volumes:
      - ./vaults:/vaults
      - ./data:/app/data
      - obsidian-app:/app/obsidian-app
    restart: unless-stopped

volumes:
  obsidian-app:

The README then directs the operator to start the service:

docker compose up -d

Open `http://localhost:8080`. On the first start, the container downloads Obsidian from its official source, and the README says to allow a minute or two. With no vault present, the interface opens the vault manager, where the first vault can be created.

The comments say that `PUID` and `PGID` should match the host user. The configuration is intentionally minimal, but it is not a complete remote deployment. The README explicitly says that Ignis has no built-in authentication. Anyone who reaches an unprotected instance can read and write the whole vault. It also says that browser features are disabled outside HTTPS or `localhost`, so a reverse proxy with authentication and TLS is required before exposing the service to other machines. The project links its remote-access and authentication documentation for that layer.

Plugin Compatibility and Browser Boundaries

Ignis supports most community plugins built on Obsidian's plugin API, according to the README. The exclusion is specific: plugins requiring Node native modules or `child_process` do not load. This is a meaningful adoption constraint. A plugin that is acceptable in desktop Obsidian may still depend on operating-system integration, subprocesses, native binaries, or filesystem APIs that the browser shim cannot provide.

The README also warns that some Electron and Node capabilities have no browser equivalent. It links to separate limitations and plugin-compatibility documentation, but does not enumerate every unsupported API or plugin. That means plugin evaluation cannot be reduced to a yes-or-no claim based on Obsidian compatibility. The plugin must also avoid the unsupported runtime features. The compatibility issue reporting guidance in `CONTRIBUTING.md` is a better place to look for project-specific evidence before depending on a plugin.

Obsidian Sync is listed as available in a logged-in tab, and server-side Headless Sync is listed as able to run without a tab open. Those are distinct deployment modes with different operational behavior. Ignis does not document their setup in the README, so users should not infer configuration details or synchronization guarantees from the feature list alone.

Filesystem Performance and Multi-Tab Operations

Ignis is designed with large vaults and slower storage in mind, but its documentation describes mechanisms rather than fixed performance numbers. A pre-compressed bootstrap response combines several kinds of startup data into one request. Live file events maintain the file tree. The indexer pre-fetch warms the content cache, and the LRU cache is documented as 50 MB by default, which the README says keeps memory use bounded regardless of vault size.

For storage behavior, Ignis can exclude paths from file watching to reduce watcher load on large vaults. It can also enable write coalescing to debounce rapid writes on slow filesystems such as rclone, FUSE, NFS, or SMB mounts. The setting is named `Write coalesce window`, and the corresponding configuration key is `WRITE_COALESCE_MS`. These controls matter because the browser client is not independent of the storage layer underneath the server.

Multi-vault support includes creating, opening, switching, renaming, and deleting vaults. Different vaults can be assigned to different browser tabs. Saved workspaces can be opened in separate tabs with the `?workspace=` URL parameter, while notes can be addressed with `?file=`. These URL features are useful for a server deployment because they make particular views easier to target, but the README does not document authorization behavior for those parameters.

Ignis Compared with a Browser-Based Alternative

The clearest alternative described by the README is a VNC-based remote desktop. The README describes VNC-based remote-access solutions as having a poor user experience. The user still operates a desktop application, so the interaction is constrained by the remote session and its user experience. The README positions Ignis differently: Ignis serves an Obsidian-compatible browser experience, keeps the vault on the server, and avoids the need for VNC.

Another practical alternative is running Obsidian locally and synchronizing notes through a separate workflow. The repository does not document a specific third-party application or compare its synchronization semantics with such a setup, so a detailed feature comparison would go beyond what the README establishes. The documented difference is architectural. Ignis is a compatibility shim around the Obsidian application inside a self-hosted server, whereas VNC leaves the desktop environment in place and remote file synchronization changes where the local Obsidian process runs.

That difference creates a corresponding security decision. Ignis exposes a browser-facing server with full vault read and write capability, so authentication and HTTPS must be supplied separately.

Maintenance, Licensing, and Upgrade Work

The repository is not archived. Its last push was on 2026-10-13, and the README states that Ignis is under active development as the author's daily driver for note taking. It also calls the project new and says gaps are documented and fixed as they arise. The release list records v0.8.17+obsidian.1.14.4 on 2026-10-11, v0.8.16+obsidian.1.13.7 on 2026-10-04, and v0.8.15+obsidian.1.13.7 on 2026-10-01. The version in `package.json` is 0.8.17, which matches the latest listed release.

Ignis is licensed under the GNU Affero General Public License v3.0. The repository metadata describes the license as custom and says to see `LICENSE`, while the README identifies the GNU Affero General Public License v3.0. That discrepancy should be checked directly in `LICENSE` and `LEGAL.md` before redistribution or commercial deployment. This is a licensing verification point, not legal advice.

Upgrade cost is not limited to changing a container tag. Obsidian itself is downloaded on first run, and Ignis releases include Obsidian versions. Operators should account for testing their vault, plugins, reverse-proxy configuration, authentication, and sync setup after an upgrade. The README points to `CHANGELOG.md` and the deployment documentation, but it does not provide a rollback procedure.

Editorial conclusion

Adopt Ignis when browser access to a server-hosted Obsidian vault matters more than desktop Electron capabilities, and do not choose it when you need native Node modules, child_process, built-in authentication, or an offline-first desktop experience. Verify first that your required plugins work without native modules, that your reverse proxy supplies HTTPS and authentication, and that your vault storage and backup process fit the documented WebSocket and filesystem model. The repository's last push was on 2026-10-13, and the README describes Ignis as under active development with documented gaps still being fixed.

Frequently asked questions

Official sources

1. Issues
2. Nystik-gh/ignis on GitHub
3. README
4. Releases