DOCS
Getting started with Core0
What to prepare before you install, the one command that starts the install, and the first things to do once the vault is running. The same steps apply to every edition; where an edition differs, the table or the text says so.
What you need
Each cell gives the minimum for stable operation, then a suggested size for around 200 requests a minute. These figures are a starting point, not a measurement under real production load. We will update them as measurements come in.
| Community | Starter | Pro | Enterprise | |
|---|---|---|---|---|
| Core0 nodes | 1 | 3 | 6 | 10 |
| vCPU per node | 2 / 2 | 1 / 2 | 1 / 2 | 1 / 2 |
| RAM per node | 6 GB / 8 GB | 2 GB / 4 GB | 2 GB / 4 GB | 2 GB / 4 GB |
| SSD per node | 20 GB / 40 GB | 40 GB / 80 GB | 40 GB / 80 GB | 40 GB / 80 GB |
| Connector machine | the same host | one more machine: 1 vCPU, 1 GB RAM (2 GB suggested), 20 GB | ||
| Admin workstation | any computer with a browser on the same LAN as the connector, able to reach its port 8443 | |||
| Operating system | Ubuntu 24.04 LTS or 22.04 LTS, a fresh install, on a static address | |||
| Outgoing mail (SMTP) | not used | required, for expiry and security notices | ||
| File storage | no | no | yes | yes |
| Replication and failover | no | no | no | yes |
If you use file storage (Pro and Enterprise), size the PII logic nodes well above the table: they unpack each file in memory and on local disk while they keep serving every other request. Plan on 8 GB of RAM for those nodes as a start, and free SSD space of at least three times your largest file. The PII data nodes need disk for the documents you store, with headroom.
Disk on the key and PII data nodes grows with the number of records. Treat the 80 GB as a starting point, not a ceiling.
Network
- Internet access on every machine during the install, for packages and the Core0 binaries. Afterwards the cluster needs only its own network and your mail relay.
- Paid editions: SSH (TCP 22) from the connector machine to every node during the install, TCP 7777 from the connector to every node, and UDP 51820 between all nodes and the connector for the WireGuard mesh.
- TCP 8443 on the connector, reachable from your admin workstation and from the application servers that will call the API. Nothing else needs to reach the cluster. Restrict 8443 with your firewall to exactly those machines.
Before you start
- The licence and the update token from your licence email. The update token is valid for 24 hours, so install soon after it arrives.
- For the paid editions: the address and the root password of every node. The installer uses the password once, over SSH, to bootstrap each node.
- For the paid editions: the details of an SMTP server Core0 can send from.
- Somewhere to keep three key shares apart: for example a password manager and two pieces of paper in two different places.
Install
Paid editions, on the connector machine:
curl -fsSL https://obsydia.tech/install.sh | sudo sh
Community Edition, on its host:
curl -fsSL https://obsydia.tech/install-ce.sh | sudo bash
The script downloads the current connector, checks its checksum before it replaces anything, starts it as a service and prints the address of the wizard:
https://<connector address>:8443/installer
Open it from your admin workstation. The connector uses a self-signed certificate, so the browser warns you once. From there the wizard asks for the licence, the token and, on the paid editions, the nodes. It shows the log line by line as it works. What the install looks like.
The key shares
At the end of the install the master key is split into three shares, two of which reconstruct it. The wizard shows them once. Save each one where the wizard tells you, apart from the others. Nobody at Obsydia ever sees a share. If you lose two of the three, the data cannot be recovered, by you or by us.
First steps
- Sign in to the panel at
https://<connector address>:8443/with the admin password you set in the wizard. - Open API Key and generate a key. It is shown once; store it with your application's secrets.
- Store a first value. The answer contains the token your application keeps instead of the value:
curl -k -X POST https://<connector address>:8443/v1/pii \ -H "X-API-Key: <your key>" -H "Content-Type: application/json" \ -d '{"field_name":"email","value":"alice@example.com","purpose":"test"}' - Read it back with the token:
curl -k https://<connector address>:8443/v1/pii/<token> \ -H "X-API-Key: <your key>"
In these two commands
-kaccepts the connector's self-signed certificate, which is fine for a first test. In your application, pin the certificate fingerprint the connector logs at start instead.
Community Edition 1.0.15: if the panel stays on its loading screen after the first sign-in, restart the connector once with sudo systemctl restart obsydia-connector-ce. This is a known issue and will be fixed.
After a restart
The key service never keeps the master key on disk. After a restart of a key node, or of the whole machine on Community Edition, the vault stays sealed until two shares are given back. Open KEK Recovery in the panel, paste two shares and confirm. Writes come back within a minute. The panel refuses the shares when the vault is already unsealed, so nothing is left on disk by a second click.
Help
Write to hello@obsydia.tech. You will get an answer from someone who works on the product.
Read the architecture and trust model