SELF-HOSTED PII VAULT
Every PII vault asks you to send them your personal data. Core0 never receives it.
Core0 runs inside your infrastructure. There is no telemetry, no remote licence check and no vendor endpoint anywhere in the request path. Tokenisation, key material and the audit log stay on hardware you control.
What leaves your network
Nothing. You do not have to take that on trust — run this against a live node and read the counter.
What it is
Core0 sits between your application and your database. Your app stores tokens. Core0 holds the personal data, encrypted at rest, behind strict access controls and a complete audit trail. When a user exercises their right to erasure, one API call handles the record, the replication log and the receipt.
Editions
Every edition runs the same binaries and the same architecture. What changes is how far it scales.
| Edition | Nodes | Includes |
|---|---|---|
| Starter | 3 | PII Tokenisation, File Storage, Email Support |
| Pro | 6 | PII Tokenisation, File Storage, Priority Support, API Access |
| Enterprise | 10 | PII Tokenisation, File Storage, Dedicated Support, API Access, Custom SLA |
Files
The same model applies to documents. Your application uploads a file and receives a token; the contents stay in the vault, encrypted with AES-256-GCM, and your database holds a reference that is worthless on its own. A leaked application database exposes no contracts, no scans of passports, no medical letters.
Structure
Folders with access control that inherits up the tree, so permissions are set once and apply to everything beneath.
Sharing
External share links for handing a document to someone outside your system, without copying it out of the vault.
Export
Streaming zip export for subject access requests and handovers.
Audit
Every read, write and deletion is recorded alongside the PII audit trail.
| POST /v1/file | Store a file, receive a token |
| GET /v1/file/{token} | Retrieve a file by token |
| DELETE /v1/file/{token} | Erasure, same guarantees as a PII record |
What differs between editions
Every edition runs the same architecture and the same binaries. Two things change with size.
Node count
A commercial deployment starts at three nodes, because KEYS, PII and Bridge are separated by design. Larger editions widen the same layout rather than replacing it — you never migrate between two different designs.
High availability
Synchronous replication between node pairs, quorum-backed service discovery and VIP failover are Enterprise features. Starter and Pro run single processes per layer with no replication: a node failure means downtime until it is restarted, and recovery comes from the snapshot schedule. That is a deliberate trade, not an oversight — most deployments do not need five-nines and should not pay for it.
Architecture
KEYS — cryptographic engine
Generates, stores and manages encryption keys. ECDSA P-256. Key material never leaves this layer and is not readable from any other part of the system.
PII — data vault
Stores encrypted personal data against tokens issued by KEYS. Field-level encryption per record, on BadgerDB storage.
Bridge — API gateway
The single entry point for your application. REST over mTLS. Handles tenant isolation, licence enforcement and routing to the service layers.
WireGuard mesh
All traffic between nodes runs over an encrypted mesh. There is no unencrypted internal communication. Consul provides discovery and health checking.
KEYS and PII are separated deliberately: compromising one layer does not expose the other. The trust model sets out what each zone can see and what it cannot.
Security model
mTLS everywhere
Every service-to-service call requires mutual TLS. Certificates renew automatically on a six-hour cycle with a fourteen-day proactive threshold.
Licence enforcement in the key layer
Licence tokens are signed with ECDSA P-256 and validated inside KEYS. Enforcement cannot be bypassed at application level, and it makes no network call: your licence file arrives by email after purchase and is loaded into the vault. Nothing phones home to check it, ever.
Shamir key recovery
The key-encryption key is split into three Shamir shares, held offline and never co-located. Recovery needs two of them and a full ceremony — there is no path that reconstructs it automatically.
Tamper-evident audit log
Every API call records actor, tenant, operation and latency. Exportable for DPA reporting.
Backup
Automated storage snapshots every six hours, plus Consul state snapshots pushed off-node.
GDPR
| Article | How it is handled |
|---|---|
| Art. 17 | Erasure deletes the record, purges the associated log entries and returns a signed receipt with timestamp and operator identity. |
| Art. 20 | Export returns every record for a tenant as machine-readable CSV — token, value, purpose, timestamp. |
| Art. 25 | Personal data is tokenised before it reaches your application database. Your app never holds raw PII — by architecture, not by policy. |
| Art. 30 | Every processing activity is recorded with purpose, actor and tenant. The audit log is your Article 30 register, maintained automatically. |
API
The Bridge API is the only surface your application touches.
| POST /v1/pii | Store a record, receive a token |
| GET /v1/pii/{token} | Retrieve a record by token |
| DELETE /v1/pii/{token} | Erasure under Article 17 |
| POST /v1/pii/batch | Batch store |
| GET /v1/export | CSV export under Article 20 |
| POST /v1/anonymize | Anonymise a record in place |
| GET /v1/audit/events | Audit log, filterable by tenant |
| GET /v1/health/full | Cluster health across all layers |