Self-hosting Obsidian notes is three different jobs people keep confusing

There is no Obsidian server, so there is nothing of Obsidian's to self-host. Obsidian's own help defines a vault as "a folder on your local file system where Obsidian stores your notes", which means the app is already running on your machine and already keeping your notes on your disk. Self-hosting Obsidian notes is therefore always about running something else next to it, and the first job is working out which something.

That is where the search results go wrong. Ask how to self-host Obsidian notes and you get back three answers that solve three unrelated problems: a sync backend so your devices agree, a container that streams the desktop app to a browser, and a static site generator that publishes a vault to the web. None of the pages ranking for this says they are different jobs. This post sorts them out, says which one you probably want, and then gets to the part all three share: a file replicator has no users in it. Baalda, the app this site is for, is a self-hostable server that does have users in it, and the honest version of this post has to say when that is overkill.

Is there an Obsidian server to self-host?

No. Obsidian is a local editor over a folder of markdown files, and the two server products in its ecosystem are both Obsidian's own hosted services.

Obsidian Sync is described in Obsidian's documentation as "an add-on service that allows you to privately sync your notes across devices". As of 10 October 2026 its pricing page lists $4 per user per month billed annually, or $5 billed monthly. Obsidian Publish is $8 per site per month billed annually. There is no server build of either to download and run. A commercial licence is listed separately at $50 per user per year, and the page is clear that it is not mandatory: "You are not required to pay for a commercial license, however if you are using Obsidian for work in an organization we encourage you to purchase a commercial license."

So "self-hosting Obsidian" is a shorthand. It means keeping the local app and replacing the hosted part with something you run.

What are the three jobs people mean by self-hosting Obsidian?

They are rarely the same job, and picking the wrong one wastes a weekend.

The middle row is the one people reach for by mistake. obsidian-remote is a Docker image whose README says it "allows you to run obsidian in docker as a container and access it via your web browser", built on linuxserver.io base images and delivered over KasmVNC. It self-hosts the application, not the notes. It is a single desktop session being streamed, so two people opening it are sharing one app and one cursor. Its README is blunt about the exposure: "do not expose this to the web unless you secure it and know what you are doing!!", and if the PASSWORD variable is unset, "there will be no auth".

That is a fine way to reach your own vault from a borrowed machine. It is not a way to give a second person their own access.

Which self-hosted sync backend should you actually run?

For the first row, which is what most people typing this query want, there are three serious answers and they are not equivalent.

Self-hosted LiveSync is the plugin that gets recommended most, and it is genuinely the closest free replacement for Obsidian Sync. Its README lists three backends: CouchDB, which you can run yourself or rent, S3-compatible object storage including MinIO and Cloudflare R2, and a peer-to-peer mode over WebRTC. It syncs notes plus settings, snippets, themes and plugins. It is also honest about its own sharp edges, and those warnings are worth reading before you commit a vault to it. The README tells you to "back up your vault" before installing or upgrading. It tells you not to enable it "alongside another synchronisation solution (including iCloud and Obsidian Sync)", and states flatly that it "is not compatible with the official 'Obsidian Sync' and cannot synchronise with it". It asks you to "avoid closing Obsidian until all progress indicators have disappeared", which it notes matters most when you have deleted or renamed files.

Syncthing is the lower-ceremony option. It calls itself "a continuous file synchronization program" and makes a point of having no central server at all. Devices authenticate each other with cryptographic certificates. For one person with a laptop, a desktop and a NAS, this is usually the right answer and it costs nothing.

Git is the right answer for a specific person: someone whose notes are mostly text they already commit, who wants history more than they want immediacy, and who does not mind resolving a conflict by hand.

If you are one person across several devices, stop here. One of those three is your answer, and the rest of this post is about a problem you do not have.

What can a file replicator never do?

Every option above moves bytes between machines. That is the whole design, and it is why they are fast, simple and free. It is also the ceiling.

A replicator has no concept of a person. Syncthing's unit is a device certificate. LiveSync's unit is a database your vault is chunked into. Git's unit is a repository. None of them has anywhere to record that Priya may read the Finance folder and Tom may not, because there is no account in the system to attach that to. The nearest thing available is a second vault, replicated to a different set of devices, which is how teams end up with four vaults and no idea which one is current.

The second ceiling is concurrent editing. A file replicator resolves two versions of a file by picking one or by writing both, because at the moment it runs, the file is all it has. The intent that produced the edits is already gone. This is the problem real-time collaboration in Obsidian runs into from the other direction, and it is not something a better sync tool fixes.

So the honest summary of self-hosting Obsidian notes is: you get full custody of your files, on infrastructure you control, with no subscription, and you get nothing at all that can say no.

What changes when the self-hosted server has users in it?

This is the gap Baalda is built for, and it is worth being specific about what you run, because "self-hostable" is a word a lot of products use loosely.

The server is one HTTP service plus Postgres. The Compose bundle in deploy/compose brings up three containers and nothing else:

cd deploy/compose
cp .env.example .env    # POSTGRES_PASSWORD, JWT_SECRET, BETTER_AUTH_URL
docker compose up -d

postgres holds the data on a named volume and is never published to the host. migrate runs the schema migration to completion and then exits. server serves the REST and auth API and the sync WebSocket on one port, 3010, so there is only ever one port to route. The ordering is deliberate: server waits on migrate succeeding, which waits on Postgres being healthy, so a deploy cannot briefly answer requests against an old schema. The server binds to 127.0.0.1 by default and the bundle's README is explicit that you put a TLS terminator in front of it before anything crosses a network.

Two details matter more than the container count.

The first is what the database actually holds. Postgres stores opaque binary CRDT updates, not your markdown. Every desktop client re-derives its own .md files on its own disk from those updates, which inverts the usual self-hosting risk. The Compose README states the consequence directly: a total server loss is recoverable from any client's vault, because every client already has the files. The volume is what lets new devices and teammates who join later catch up, not what stands between you and your writing. That is the opposite of the CouchDB arrangement, where the database holds the content and losing it means restoring from a backup you hopefully took.

The second is that the server has accounts, so permissions have somewhere to live. Notes are private by default, and a folder or a single file is shared with the whole team or one named person, as view or as edit. The same per-folder rules gate an AI connecting over the MCP endpoint at your server's URL plus /api/mcp, so an assistant reaches exactly what the person who issued its token reaches. Onboarding the team is a link: a self-hosting admin sends https://<your-server>/open/connect and the desktop app points itself at that instance.

Two smaller things worth knowing before you compare costs. Billing is off in a self-hosted deployment, and billing off means no limits: unlimited vaults, unlimited members. And the licence is Apache-2.0 for the entire core, with one carve-out, the ee/ directory, reserved for future commercial-only features like SSO and audit logs. As of today that directory contains a licence file and a readme and no features at all, and the repository's own ground rule for it is that enterprise features "must never remove or gate a capability that already shipped under Apache-2.0". There is more detail in the self-hosting docs.

Where is this the wrong choice?

Four places, and they are real.

• You are one person. If nobody else needs your vault, Syncthing or git is the correct answer and this is strictly more machinery for no benefit. Permissions with one account are a no-op.
• You do not want to operate anything. This is Postgres, a container runtime, a TLS terminator and a backup you have to actually take. Syncthing is an app you install. Those are not the same commitment, and pretending otherwise would be dishonest.
• You want to keep using Obsidian. Baalda is a different editor over the same kind of folder, not a backend that Obsidian plugs into. There is no importer either: you point it at a folder of markdown and the files are the notes. How the two compare covers where Obsidian is still the better app, and it genuinely is for plugin breadth and for the ecosystem around it.
• You are building the desktop client from source. The repository's documented prerequisites for that are Linux-only today, because of Tauri's system dependencies and the Secret Service keychain backend. Prebuilt apps cover macOS, Windows and Linux, but a from-source build on macOS is not a documented path.

So which one should you run?

Match it to the sentence you would actually say out loud.

• "My notes should be current on all my machines." Syncthing, or Self-hosted LiveSync if you want Obsidian's settings and plugins to travel too. Read LiveSync's warnings first and back the vault up.
• "I want to open my vault from a browser on someone else's computer." obsidian-remote, behind a VPN or an authenticating proxy, with the password set.
• "I want my notes readable on the public web." Quartz or Perlite, which build a site and leave the vault alone.
• "Another person needs their own access, and not to all of it." None of the above can do this, and that is not a gap a sync tool will close. You need a server with accounts, which means changing app rather than changing backend.

The useful question underneath all of this is not whether something can be self-hosted. Most of these can. It is what the thing you self-host knows about the people using it, and a file replicator, by design, knows nothing. That is fine until the day a second person needs half a vault. There is more on the general shape of that trade in open source and local-first notes.