sytone/obsidian-remote: running Obsidian in a container and opening it in a browser

What the container actually gives you

Obsidian ships desktop builds for Windows, macOS and Linux. There is no server build. sytone/obsidian-remote works around that by running the Linux AppImage inside a container and exposing the desktop session through a browser, so a machine that cannot install the desktop app can still open a vault. The intended user is someone with a home server, a NAS or a VPS who wants the same vault reachable from a work laptop or a tablet browser without installing anything locally. The README is direct about the boundary: use http://localhost:8080/ locally, and do not expose it to the web unless you secure it and know what you are doing. That sentence sets the tone for the whole project. This is a single-user access layer for a vault directory you already own, not a multi-tenant service and not a sync product.

How the KasmVNC base and the AppImage fit together

The Dockerfile starts from ghcr.io/linuxserver/baseimage-kasmvnc:debianbookworm. KasmVNC is what turns a Linux X session into something a browser can render, which is why the container can serve a desktop application over HTTP at all. On top of that base the build installs a fixed list of Debian packages (curl, libnss3, zlib1g-dev, dbus-x11, uuid-runtime, libfuse2 and the GTK and ATK libraries Obsidian links against), then downloads the Obsidian AppImage for the pinned OBSIDIAN_VERSION, marks it executable, runs it with --appimage-extract, and deletes the AppImage. Extraction matters: it avoids needing FUSE at runtime for the app itself, though libfuse2 is still installed. The architecture handling is a single shell trick in the Dockerfile: FLAG=${TARGETARCH#amd64} strips the string amd64 from the build architecture, so an amd64 build downloads the plain AppImage and an arm64 build downloads the -arm64 variant. Two volumes carry state: /vaults for vault files and /config for Obsidian configuration and SSH data used by the obsidian-git plugin. The container also declares a healthcheck that curls the HTTP port, adding --user when CUSTOM_USER and PASSWORD are both set.

Installing it and opening a vault in the browser

The README gives a Linux example that creates the two host directories first and then runs the container in the background. Run it, then open http://localhost:8080/ and you should land on the Obsidian interface with the /vaults directory available to open as a vault.

mkdir -p ob/{vaults,config}
docker run -d \
  -v ./ob/vaults:/vaults \
  -v ./ob/config:/config \
  -p 8080:8080 \
  ghcr.io/sytone/obsidian-remote:latest

Adding git, fonts and a keyboard layout

Two environment variables extend the image without a rebuild. DOCKER_MODS pulls in LinuxServer mods, and the README's example is DOCKER_MODS=linuxserver/mods:universal-git, which is what the obsidian-git plugin needs to run git inside the container. INSTALL_PACKAGES installs extra Debian packages at startup, and the README pairs it with the linuxserver/mods:universal-package-install mod, giving INSTALL_PACKAGES=fonts-noto-cjk fonts-noto-extra as the example for CJK coverage. KEYBOARD takes values such as en-us-qwerty or de-de-qwertz, and the README points at the digikam container's keyboard layout list for other values, noting they are not tested.

docker run -d \
  -e DOCKER_MODS=linuxserver/mods:universal-git \
  -e INSTALL_PACKAGES=fonts-noto-cjk \
  -e KEYBOARD=de-de-qwertz \
  -v ./ob/vaults:/vaults \
  -v ./ob/config:/config \
  -p 8080:8080 \
  ghcr.io/sytone/obsidian-remote:latest

Authentication defaults that need changing before anything else

CUSTOM_USER and PASSWORD are the HTTP Basic credentials for the web interface. The README states that abc is the default for both, and that if PASSWORD is unset there will be no auth at all. The Dockerfile sets both to empty strings in the image environment, which means a container started with no overrides runs unauthenticated. That is fine on a loopback port and wrong the moment the port is reachable from anywhere else. The healthcheck reflects the same logic: it only adds --user when both variables are non-empty. If you put the container behind a reverse proxy, the README covers nginx and Nginx Proxy Manager and documents SUBFOLDER for subfolder hosting, with the note that both slashes are required, as in /subfolder/. CUSTOM_PORT and CUSTOM_HTTPS_PORT exist if 8080 and 8443 collide with something else on the host. PUID and PGID default to 911 and control the container user, which is how you line file ownership up with the account that owns /vaults on the host.

Where this is the wrong tool

The README says nothing about merging concurrent edits. If you open the same vault in the container and on a desktop machine at the same time, nothing in this project reconciles the two writes; that is the job of whatever sync layer you put underneath, and the container has no opinion about it. The same silence applies to encryption: there is no vault encryption, no password-protected remote vault and no transport security beyond what you configure, so the HTTPS port on 8443 and any reverse proxy TLS are your responsibility. It is also the wrong choice for mobile. The project serves a desktop application through a browser session, not a native app, so the Android and iOS clients people search for are not what this provides. And it is not a way to make an existing vault remote in the sync sense: mounting /vaults points the container at files that already exist on that host, which means the vault must already be on the machine running Docker. If your notes live on a laptop and you want them on a server, this container does not move them.

How it differs from Obsidian Sync and from a plain shared folder

Obsidian Sync is a paid first-party service that replicates a vault between devices and handles conflict resolution and encryption as part of the product. sytone/obsidian-remote does none of that. It renders one vault, on one host, in a browser tab. The practical difference shows up the moment you have two writers: Sync has a merge story, this container has a mount. A second alternative is simpler still: keep the vault in a shared folder or a git repository and run the desktop app on each machine. That avoids the container entirely, but it requires installing Obsidian everywhere and it does not help on a device where you cannot install software. The container's real advantage is that it needs nothing on the client beyond a browser, which is also exactly why it is a weaker fit for anyone who wants their notes available offline on a phone.

Upgrades, the pinned version, and what the MIT licence covers

Obsidian's version is fixed at build time through the OBSIDIAN_VERSION build argument, set to 1.8.10 in the Dockerfile. The README has an Updating Obsidian section and a Building locally section, and the mechanism is a rebuild rather than a runtime upgrade: pulling a new image only helps once the maintainer has rebuilt it against a newer release. The repository's most recent tagged release is v0.1.1 from 2022-10-10, so the tags do not track the application version; the last push to the repository was on 2026-09-06, which is where the current state of the image lives. The project is MIT licensed, and the Dockerfile carries Open Container Initiative labels including org.opencontainers.image.source. The licence covers this repository's own files. It does not cover Obsidian itself, which the build downloads from the obsidian-releases GitHub releases at image build time, so anyone redistributing a built image is bundling a proprietary application and should read Obsidian's own terms rather than assume the MIT grant extends to it.

Editorial conclusion

Adopt sytone/obsidian-remote if you want browser access to a vault that already lives on a machine you control, and you accept that the container holds the vault rather than syncing it. Do not adopt it as a replacement for Obsidian Sync or a hosted vault service: there is no conflict resolution, no encryption layer and no mobile client here, and the README explicitly warns against exposing the port to the web. Before committing, verify three things: that your architecture has an image tag (the ARM image is published as sytone/obsidian-remote:arm64 on Docker Hub, not on the GitHub Container Registry), that your vault is backed up outside the /vaults mount, and that you are willing to rebuild the image to move past the pinned OBSIDIAN_VERSION build argument.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. sytone/obsidian-remote on GitHub