Hey @oceanbyte,
Thanks for the kind words. We’re really excited to be working on this product, and your questions make a lot of sense. We’re hearing from more and more companies that they are interested in privacy-preserving local-first collaboration.
We’re currently focused on self-hosting over end-to-end encryption as we’ve found that our current customers are happy with this trade-off. When we eventually offer e2ee, it will likely be in the context of individual users keeping their vaults in sync.
Regarding permissions, RBAC is a focus for us right now. For version history, we can turn on bucket versioning which provides (by default) 10s snapshot granularity - unfortunately we haven’t completed an in-app browser for historical versions. We also have a server-side Git integration that can push changes to a git server. This can be self-hosted and can also be useful for publishing internal documentation.
Self-hosting –
We’re currently leaning into our hybrid deployment model. While it is possible to self-host the control plane (and we might do it for the right partner) there is an order of magnitude more complexity in managing the deployment, updates, migrations, etc. The two properties that are most important to us (and our customers so far) are (1) complete document privacy, and (2) that the Relay Server does not require a connection to the internet (or our server). Our hybrid deployment model delivers on that.
Large Files –
Our limitation on large files within Obsidian is because Obsidian does not expose a streaming write API, which means that all files must be able to fit into memory on any user device. We have some ideas for how to work around this, but mobile support remains a particular challenge.
Performance –
The server is written in Rust and consumes very few resources. I have never seen any of our servers use more than 6% CPU on the smallest potato-of-a-VM available on fly.io.
Identity / SSO –
Currently OIDC only. We could add additional support, but our existing customers have been fine with this so far. We have a user-management API, but it isn’t SCIM compatible.
High-availability –
The Relay Server must be run as a single instance, but it is also stateless (it stores all state on S3-compatible storage) so it can be cheaply destroyed and recreated. In my opinion, the simplicity of destroying and recreating a new machine outweighs the risks of running a single instance. Importantly, when the Relay Server is down, everyone can continue working independently as the documents exist locally and work offline by default.
Compliance –
We did a push for some on-prem enterprise deals recently, but the overhead of the deal process was taking away from building core-product. We’re currently waiting until we find the right partner, perhaps in 2026. In the meantime, we’re focused on small-to-medium businesses and our own internal security/compliance audits. The Relay Server and our Obsidian Client are open source (MIT license) for transparency.
Our security whitepaper is also available by request. At a high level our control plane uses KMS to sign CBOR Web Tokens (CWTs) with an EdDSA signature. Each token grants an individual user access to an individual document for ~30 minutes. The Obsidian plugin passes this token to the Relay Server which validates the token against the configured public keys. Our primary infrastructure is in the US (all persisted data is resident to the US), though we do operate edge servers globally for latency/performance. For customers wanting to use our cloud service we can easily deploy Relay Servers to arbitrary regions.
Feel free to follow up with us via discord or email if you’d like to discuss anything here in detail.