Set Up Obsidian Sync as a Self-Hosted Note Server

Taking Your Notes Off the Cloud

Obsidian is built around a simple promise: your notes are plain markdown files stored locally, owned entirely by you. The official Obsidian Sync service extends that to cross-device access for a monthly fee, but a growing number of users would rather run their own sync infrastructure than pay recurring costs or hand any metadata to a third-party server. Self-hosting solves both problems at once.

The good news is that Obsidian does not require a proprietary protocol to sync. Because vaults are just folders of files, you can use a WebDAV-compatible server to replicate them across devices using the Remotely Save community plugin. This guide walks through setting up a self-hosted WebDAV endpoint using Docker, connecting it to Obsidian on desktop and mobile, and hardening the setup so it does not become an open relay for your personal notes.

What You Actually Need Before Starting

The minimum requirement is a machine that stays online – a home server, a Raspberry Pi 4, or a small VPS all work. You need Docker and Docker Compose installed, a domain name or local hostname you can reach from your devices, and ideally a valid TLS certificate so traffic is encrypted in transit. If you are running this purely on a local network, a self-signed certificate with a trusted root pushed to your devices is acceptable. Exposing an unencrypted WebDAV endpoint to the public internet is not.

Port forwarding on your router is required if you want to reach the server from outside your home network. Forward TCP port 443 to the machine running the container, or use a reverse proxy like Nginx Proxy Manager or Caddy to handle TLS termination. If your internet service provider blocks inbound port 80 and 443, a Cloudflare Tunnel or a WireGuard VPN back into your home network are both viable alternatives that avoid opening ports entirely.

Setting Up the WebDAV Container

The cleanest Docker image for this purpose is bytemark/webdav, which wraps Apache with WebDAV modules enabled and accepts environment variables for user credentials. Create a working directory, then drop a docker-compose.yml file inside it. The service definition needs four things: the image name, the port mapping (typically 80 inside the container mapped to whatever port your reverse proxy will target), a volume mount pointing to a local folder where vault files will live, and the environment variables AUTH_TYPE, USERNAME, and PASSWORD.

Set AUTH_TYPE to Digest rather than Basic. Basic authentication sends credentials in base64, which is trivially reversible if someone intercepts the traffic. Digest authentication hashes the exchange, giving you a second layer of protection even if TLS ever hiccups. Your compose file should also declare a named volume or a bind mount to a path outside the container so vault data persists across container restarts and image updates.

Once the file is saved, run docker compose up -d from that directory. Confirm the container started with docker compose ps and check logs with docker compose logs webdav if anything looks wrong. At this point the server is reachable on its internal port. Point your reverse proxy at it, assign a subdomain like dav.yourdomain.com, and let Caddy or Nginx provision a Let’s Encrypt certificate automatically. Test the endpoint by opening the URL in a browser – you should see a digest authentication prompt, and after logging in, an empty directory listing.

Before connecting Obsidian, create a subfolder inside the WebDAV root for each vault you plan to sync. Mixing vaults at the root level works but becomes messy when you have more than one. A structure like /dav/personal/ and /dav/work/ keeps things clean and makes it easier to set up per-vault credentials later if you ever want to share one vault with a collaborator without exposing everything.

Installing and Configuring Remotely Save

Remotely Save is a community plugin, so you need to enable community plugins in Obsidian’s settings before it appears in the plugin browser. Search for “Remotely Save,” install it, and enable it. The plugin supports S3-compatible storage, Dropbox, OneDrive, and WebDAV – select WebDAV from the provider dropdown.

Fill in the server address as your full subdomain URL including the path to the vault subfolder, for example https://dav.yourdomain.com/personal/. Enter the username and password you set in the container environment variables. Leave the auth type on auto-detect unless you run into issues, then force it to Digest. Hit the connectivity check button – if the plugin returns a success message, the credentials and path are correct. Save the settings and trigger a manual sync once to confirm files actually move to the server directory.

Syncing on Mobile

The Remotely Save plugin works identically on iOS and Android through the Obsidian mobile app. Install the app, create a new vault with the same name as your desktop vault, enable community plugins, install Remotely Save, and enter the same server address and credentials. On the first sync the plugin downloads the full vault contents from the server, which on a large vault with many attachments can take a few minutes over cellular.

One practical consideration for mobile: set the plugin to sync on app open and app close rather than on a timer. Background app refresh on iOS is unpredictable, and a timer-based sync that fires while the app is backgrounded may silently fail. Syncing on open and close captures the most important moments – when you start a session and when you finish one – without relying on system behavior you cannot control.

Conflict handling in Remotely Save defaults to keeping the newer file when timestamps differ. This works for most situations but can lose edits if two devices edit the same note while both are offline. The plugin logs conflict events, so periodically reviewing those logs on an active multi-device setup is worth the two minutes it takes. For anyone already running a self-hosted password manager, the server discipline required here is similar to what you would apply to a Vaultwarden instance – keep containers updated, rotate credentials on a schedule, and restrict access to known IP ranges where your setup allows it.

Keeping the Setup Secure and Maintainable

Running an internet-facing file server for personal notes means access control deserves real attention. Beyond the digest authentication on the WebDAV layer, configure your reverse proxy to block anything except GET, PUT, DELETE, PROPFIND, MKCOL, and COPY – the methods WebDAV actually needs. Dropping unexpected HTTP verbs at the proxy level reduces attack surface without touching the container. If your reverse proxy supports IP allowlisting, restricting the subdomain to your home IP and any static VPN exit nodes is worth doing even if it occasionally inconveniences you when traveling.

Container maintenance is the other half of the equation. Pin the bytemark/webdav image to a specific digest in your compose file rather than using the latest tag, then set a calendar reminder to check for updates monthly. When you update, pull the new image, bring the container down, bring it back up, and verify the WebDAV connection still works from both desktop and mobile before closing the terminal. The vault data lives in the bind mount outside the container, so updates carry no risk of data loss – but verifying connectivity takes thirty seconds and removes all doubt.

One question that comes up consistently is whether to encrypt vault files at rest on the server. The WebDAV container stores files as plain markdown, so anyone with server access can read them. Obsidian does not natively encrypt files at the vault level, but the Obsidian community plugin Encrypt All Files and similar tools can layer encryption on top before files ever leave your device. Whether that extra step is necessary depends entirely on your threat model – someone with physical or root access to your server is already a serious problem, but encrypting at the client side means the server operator, or anyone who compromises the box, sees only ciphertext.