Private storage API · Türkiye

Your data,encrypted.Your deletions,provable.

Customer records, transaction history, application logs, device data: Reindeer seals every JSON record with its own key, keeps the data on a closed IPFS network in Türkiye and holds the keys in HSMs. When you delete a record, its keys are destroyed and you receive a signed erasure certificate.

Open console Read the docs

Any JSON dataAES-256-GCMA key per recordClosed IPFS networkKeys in HSMsTwo-person ruleDeletion by ownerSigned receiptsProvable deletionData in TürkiyePasskey sign-inMachines on mTLS

Data

Anything that is JSON.

Reindeer is not tied to a data format. Every record carries an id, an owner and a timestamp, and you say which fields those are with JSON pointers when you open an ingest session. The owner id lets you delete every record of one person or entity with a single request.

01Customer recordsProfiles, memberships, preferences
02Transaction historyOrders, payments, movements
03Application logsEvents, access and audit records
04Device dataSensor readings, telemetry
05Document recordsFile metadata, contract summaries
06Content archivesPosts, messages, comments

partition crm

{ "customer_id": "c-1042", "account": { "id": "a-77" }, "updated_at": "2026-10-07T09:12:00Z", "plan": "pro"}

id: /customer_id
owner: /account/id
time: /updated_at · rfc3339

{ "order_id": "o-58213", "buyer_id": "u-77", "placed_at": "2026-10-06T18:40:00Z", "total": 1290}

id: /order_id
owner: /buyer_id
time: /placed_at · rfc3339

{ "reading_id": "r-9001", "device": { "id": "d-14" }, "ts": 1791370000, "celsius": 21.4}

id: /reading_id
owner: /device/id
time: /ts · unix

{ "id_str": "1839000000000000005", "user": { "id_str": "9005" }, "created_at": "Tue Oct 06 18:40:00 +0000 2026", "text": "..."}

id: /id_str
owner: /user/id_str
time: /created_at · twitter

Journey

The path of a record

Every step from upload to destruction can be measured and audited.

A record arrives

Your source system sends NDJSON batches over mutual TLS. Nothing is published before the batch digest verifies.

Sealed with its own key

Every record is compressed and encrypted with its own AES-256-GCM key. That key touches no other record.

Written to a key block

Record keys are collected in a key block per chunk; the block is wrapped by the epoch key and the DR key.

Kept on a closed network

Encrypted chunks are pinned on a private IPFS network of nodes that hold the swarm key. There is no path to the public network.

Deleted means gone

A deletion enters the ledger, the weekly roll removes the record from the key blocks, and the old epoch keys are destroyed inside the HSMs.

NDJSON · mTLS

Guarantees

What the design promises

Record-level encryption

Every record and every version of it is sealed with its own key; record keys live only inside the per-chunk key blocks.

Closed IPFS network

Data stays on a private network of nodes that hold the swarm key; there is no gateway and no DHT.

Provable deletion

Deleted records drop out of reads at once; once their keys are destroyed, copies in backups cannot be opened either.

Two-person rule

Every sensitive action waits for a second person's passkey approval; nobody approves their own request.

Verifiable audit

Key journals are hash chained and sealed with signed checkpoints; you run the verification yourself.

Keys in HSMs

Epoch, recovery and signing keys are generated inside the HSMs and stay there, non-extractable.

Deletion

Delete means delete.

Deleted records drop out of reads at once. Once the keys that protected them are destroyed, even the encrypted copies left in backups cannot be opened.

7dayssafety window

RequestThe deletion enters the ledger.
RollThe weekly roll removes the record from the key blocks.
WaitOld keys are kept safe for seven days.
DestroyThe epoch keys are destroyed inside the HSMs.
CertificateA signed erasure certificate is issued.

Approval

One person asks. Someone else approves.

Batch deletions, full exports, new identities, key loss declarations and organisation activations wait for a second person's passkey approval. Neither the requester, nor whoever invited them, nor anyone in their control chain can decide.

Requester

Approver

256 bitEach record has its own key

7 daysSafety window before destruction

2 peopleFor every sensitive action

1 cellPer customer

Platform

A cell for every customer

Sign up; two operators review and activate your organisation. A cell of your own is prepared: its own API address, database, private IPFS network, HSM partition and signing key. No request, query or key is shared with another customer.

01Sign up
02Review
03Activation
04Your cell

Keep your archive safe.

Create an organisation Docs