HOW IT WORKS

What installing Core0 actually looks like

Core0 runs on machines you own. There is no account to create, no endpoint to call home to, and no stage where your data passes through us. This page walks through an install as the person doing it sees it, using screenshots from a real deployment rather than diagrams of an idealised one. Tap or click any screenshot to open it full size.

What to have ready

One person can run the whole thing, in an afternoon. It is not a project that needs a team of engineers or a quarter of planning. What it does need is a short list of things prepared beforehand, because the wizard asks for them and will not proceed without them.

• A machine for the connector, running Ubuntu 24.04 or 22.04. This one is not temporary: it joins the WireGuard mesh during the install and stays part of it, as the only gateway between your network and the cluster. The admin panel and the API are served from it on port 8443, so you administer Core0 from a browser on the same LAN, and you restrict that port with your firewall to your admin workstation and the application servers that call the API. Treat it accordingly — it is not a laptop you hand back at the end of a contract.
• Machines for your nodes — three, six or ten depending on the tier (Community Edition runs everything on one machine), running Ubuntu 24.04 or 22.04, on static addresses. A fresh install is easiest; anything already running Docker or nginx will get in the way.
• The root password for each node. The installer connects over SSH and uses the credentials once, to bootstrap.
• Internet access on the nodes during installation, for package downloads. Once the mesh is up the nodes only need to reach each other and your mail server, so with an internal relay the cluster can come off the internet entirely.
• Somewhere to keep the three key shares apart — for example a password manager and two pieces of paper in two different places.
• For the paid editions, SMTP details for an address Core0 can send from — your own internal relay, or an external provider if you would rather. It is how the system tells you about expiry and security events, and it is the only thing the cluster reaches out to once it is running.
• Disk space for what you intend to store. The requirements table gives the minimum and a suggested size per node for each edition; if you are running ObsydiaFiles, the PII data nodes need room for the documents on top of that.

That is the whole list. Sizes per edition, the ports to open and the install command are on Getting started.

You supply the machines

You give the installer an address and a login for each node. The tier decides how many: three for Starter, six for Pro, ten for Enterprise. Roles are assigned for you — key nodes, PII nodes, logic, bridge, witness — because getting that split wrong is what makes a vault a single point of failure.

SSH credentials are used once to bootstrap each node. They are not written to disk and not sent anywhere outside your network.

The installer builds the network before it builds the vault

Before any Core0 service starts, the installer establishes a WireGuard mesh between every node, applies nftables rules and, on Enterprise, brings up a Consul quorum. Only then do the services deploy. You watch it happen line by line — the log is the interface, not a progress bar with a spinner over it.

Ten nodes joining a mesh, each verified reachable from every other, before a single record exists.

The keys are yours, in the strictest sense

At the end of the install, the master encryption key is split into three shares using Shamir Secret Sharing. Two of the three reconstruct it. The wizard assigns each share a destination — paper in one location, a password manager, paper in another — so the shares are separated by default instead of ending up in one drawer.

Share values are redacted here. In a real install they appear once, on your screen, and are seen by nobody but the person sitting in front of it.

Two consequences follow, and both are worth stating plainly. Nobody at Obsydia ever sees a share, so we cannot read your data and cannot be compelled to hand over a key we do not have. And if you lose two of the three shares, the data is gone — for you and for us. There is no vendor override, because a vendor override is exactly the thing this design exists to remove. If you need a copy that survives the loss of the vault, export your records from the admin panel. The file holds the values in plain text, so keep it as carefully as the data itself.

Then it hands over and gets out of the way

Smoke tests run, the installer confirms the instance is live, and that is the last time it is involved. There is no ongoing connection back to us, and no licence check that phones home.

The instance is yours from this point. Updates are something you pull when you choose to.

What you can see afterwards

The client panel shows the state of the system without exposing what is in it: record counts, service health, replication lag per node, certificate expiry, licence term remaining. Enough to operate the vault, not enough to read it.

On Enterprise, replication state is per node and per stream, so a replica falling behind is visible before it matters.

Every access is recorded, and the record resists tampering

Each audit entry carries a sequence number and the hash of the entry before it. Change or remove one entry and the chain no longer verifies. The chain survives service restarts, which is the part that is easy to claim and easy to get wrong.

Actor, action, key used, sequence, and the previous hash — enough to reconstruct who touched what, without the entry containing any personal data itself.

What this page does not cover

This is the happy path. The trust model — what each zone can see, what an attacker holds after compromising one, and which failures the design does not defend against — is written up separately, in more detail and with less optimism.