Karsten Lehmann 11 July 2026 15:01:00
A lot has happened since our last blog post at the end of May. Over the coming posts I want to walk you through all of it - and I want to start with the piece that changes what kind of organisation can put its data into Haven at all.
Here is the situation every growing team eventually runs into. In a small, fully-trusted group, everybody can see everything and everybody is allowed to change everything, and that is exactly right - it keeps things simple. But as soon as a real organisation is involved, a new word appears: rules. Not everyone should be able to delete customer records. The new intern should be able to read the handbook but not rewrite the price list. And months later, a colleague from compliance will stand at your desk and ask the question that is surprisingly hard to answer in most systems: “Who was actually allowed to do this, and when?”
That is what we built, and it is available today in Haven Enterprise - which, like Haven Community, is currently in beta. Haven Community stays what it has always been: the end-to-end-encrypted, local-first workspace, free to use for both private and commercial projects and without any key to unlock. Haven Enterprise adds a governance layer on top of that same foundation and is switched on with a license key. Nothing about the Community experience changes.
Encryption was always half the story
MindooDB has protected your data from day one by encrypting it, so the only people who can read a document are the ones who hold the key it was locked with. The server that stores and syncs your data never sees anything but ciphertext. That is a strong guarantee, and it is why you can host MindooDB anywhere without handing your secrets to whoever runs the machine.
But reading is only half the story. Holding a key lets you read a database - and, until now, anyone who could read it could also create, change and delete documents in it. For an organisation that is too coarse. The new governance layer adds the missing half: fine-grained control over who may write what, and where - and, separately, control over who may see which data at all by deciding who receives which keys.
Rules that live in the same tamper-evident history as your data
The idea that makes this trustworthy is almost boringly simple, and it is the same idea that already makes MindooDB special.
MindooDB never overwrites anything. Every change is added to an append-only history, each one signed by the person who made it and cryptographically linked to the change before it - like a block in a blockchain. You cannot quietly rewrite the past, because breaking one link breaks every link that follows.
We store the access rules the exact same way. Turning a rule on, changing who is in a group, granting or removing someone’s rights - each of those is itself a signed entry in the shared history that every device syncs. That has a lovely consequence: the complete story of your organisation’s rules is preserved forever, right next to the data those rules governed. You can go back and see, for any moment in the past, who had access to a database or a document, and how a single person’s access changed over time - all without any separate audit product bolted on the side. The history is the audit trail.
The trick that makes it work offline: a trusted date
Here is the part I find genuinely elegant, and it is the reason this works in a local-first world where people are constantly offline.
Imagine someone loses the right to change a database on Monday. On Tuesday, offline on a train, they make a change anyway - and, feeling clever, they set their laptop’s clock back to last week to make it look like the change happened while they were still allowed. In most offline systems that is a real problem, because the only clock available is the one on the device, and the device’s owner controls it.
MindooDB refuses to trust that clock. When a change finally reaches the server, the server stamps it with its own trusted date - “I received this at this moment” - and signs that stamp together with the change. From then on, every access decision is judged against that trusted date, not against whatever time the laptop claimed. A change made after you lost a right simply cannot be smuggled in with a backdated clock, because the moment that counts is the moment the server saw it, and that moment is signed and cannot be forged.
This also answers the offline question the friendly way. If you have lost a right, your offending change just won’t sync - it stays stuck on your own device and never spreads. And if you regain the right later, the very next sync goes through cleanly, stamped with the correct current date. Nobody has to babysit any of this.
Two kinds of protection, both real
Some rules can be checked by the server itself, because they only involve things the server can see without ever reading your data - who you are, which database you are writing to, whether you are creating or deleting. The server enforces those against everyone, so a violating change can never even enter the system.
Other rules are about the content of a document - and here is the thing, the server can never read content, and we would never want it to, because that is the whole promise that lets you host Haven anywhere. So content rules are enforced by every honest device the moment a change arrives. If a change breaks a content rule, the receiving device quietly sets it aside into a quarantine - it never becomes visible and nobody can build on top of it - and it shows up in Haven’s audit view so an administrator can see what happened. Your organisation’s shared data stays consistent for everyone, and the server never had to see a single word of it.
Setting an organisation up for success: policies
Governance is not only about saying “no”. A big part of a good workspace is what a new colleague sees on their very first day.
Haven Enterprise adds policies for exactly that. An administrator can pre-configure the Haven experience for people who are being onboarded - for example, setting up their Sync page and kicking off the initial syncs so the data they need is already there, offline, before they even ask for it. A policy can even distribute the apps people should have, so the right applications are already installed and pointed at the right tenants. Policies are configured on the Tenants page in Haven’s preferences, stored in an administrator-only area that regular users can’t tamper with, and then distributed automatically with the normal sync. Set it once centrally; everyone benefits.
Put the two together - apps distributed by policy, and their data pulled down by the initial sync - and the payoff is a lovely first-day experience: when a new colleague opens the app for the very first time, it is already installed, already connected to the right tenant, and already full of the data they need. Everything is simply ready to go, with nothing to set up by hand.
Handing over keys without handing them to the admin
The most subtle piece is about keys, and it is my favourite because it keeps the zero-knowledge promise fully intact.
Remember: in MindooDB, being able to read data means holding the right key. So distributing and revoking keys is how you actually control who can see what. The obvious way to do that at scale would be to let an administrator manage everyone’s keys - but then the administrator could read everything, and the whole point of end-to-end encryption would be gone.
So we built admin-blind key distribution. When someone wants to share a key, they put it into a sealed envelope addressed to a specific recipient - sealed in such a way that only that recipient can open it. The administrator’s system carries the envelope along with the regular sync and can also invalidate keys when access should end, but the administrator can never look inside. The key travels through the middle without the middle ever being able to use it. You get central, automatic key distribution and revocation, and you keep the guarantee that the people running the infrastructure cannot read your data.
Wiping a device that shouldn’t have the data anymore
Revoking someone’s keys stops them reading anything new, but it doesn’t reach back to the copy already sitting on a laptop that was just left on a train. For that, an administrator can now trigger a remote wipe on a per-device basis: point it at a specific device, and Haven’s data on that device is cleared. It is the answer to the lost phone, the stolen laptop, and the colleague who has left the organisation - you deal with the one device that is a problem, without disturbing anyone else’s.
Why this matters
Put together, this turns a superb personal and small-team database into infrastructure a whole organisation can stand on:
- Clear rules about who may create, change and delete - scoped to a database and even to the content of documents.
- Honest enforcement offline, because decisions are judged against a trusted date the server signs, not a device clock anyone can wind back.
- A built-in, tamper-evident audit trail, because the rules live in the same append-only history as the data. “Who could do what, and when?” is finally a question with a provable answer.
- Central key management that stays end-to-end encrypted, so administrators can distribute and revoke access without ever being able to read the data themselves.
- A per-device remote wipe, to clear Haven’s data from a specific lost, stolen or retired device without touching anyone else’s.
And it is all opt-in. An existing tenant behaves exactly as before until an administrator turns governance on, and nothing that already happened is retroactively invalidated. If you never need it, you never see it.
How to get it
Governance, policies and admin-blind key distribution ship with Haven Enterprise, which is currently in beta and unlocked with a license key. Haven Community remains free to use for private and commercial projects and fully end-to-end encrypted - the same base it has always been. If you would like to try the Enterprise beta in your organisation, get in touch with us at mindoodb.com, and you can read more about the access-control model on the MindooDB website.
This is the first of several posts catching up on everything we shipped over the summer. Next up: how Haven answers questions across thousands of documents without ever opening a single one.