Ephemeral compute.Permanent proof.
A sealed environment for regulated data. Your workflow stays the same. Nothing persists — architecturally, not by policy.
The environment disappears. The evidence remains.
Free tier available · No credit card
What every capsule produces.
A signed, timestamped record of what happened — independently verifiable. Your compliance team maps it to their frameworks. Your auditor checks it.
Cryptographic proof that the environment was sealed, controls were active during execution, and destruction completed. Every step signed. Every step chained to the last. Tamper-evident by construction.
Every framework listed asks for the same kind of evidence — isolation, processing integrity, verified destruction. One artifact. Whether it satisfies a given control is your auditor’s call, not ours.
Your complete operational record stays with you. This is the verifiable portion — what your auditor checks, what your customer’s compliance team receives, what a regulator can independently verify.
30 seconds. No portal. No vendor call. No active subscription. Verification needs nothing but the file itself.
One proof. It travels — to your auditor, to your customer’s compliance team, to a regulator. Anyone can verify it independently.
Three lines wrap your existing process in a sealed, provable environment.
No workflow migration. No data routing changes. No SDK lock-in. Your pipeline stays the same — it just runs inside a capsule now.
import nanorix # Start a capsule, run your work, get the proof result = nanorix.run( capsulefile="process.Capsulefile", files=["records.csv"] ) # Your AuditProof print(result.cdp.verification_hash) # sha512:2c8a4f63d19e7b5a...
import { Nanorix } from '@nanorix/sdk'; // Start a capsule, run your work, get the proof const result = await nanorix.run({ capsulefile: 'process.Capsulefile', files: ['records.csv'] }); // Your AuditProof console.log(result.cdp.verificationHash); // sha512:2c8a4f63d19e7b5a...
# Create a capsule POST /v1/capsules Authorization: Bearer nrx_live_... Content-Type: application/json { "data_classification": "PII" } # Upload data POST /v1/capsules/{id}/files Content-Type: multipart/form-data # Destroy and get AuditProof POST /v1/capsules/{id}/destroy # Response { "cdp": { "hash": "sha512:2c8a...", "signature": "ed25519:...", "steps": 8, "verified": true } }
Start free.
Evaluate with real workloads. Every capsule produces a signed, independently verifiable AuditProof on every plan — including one whose destruction did not complete, which is signed as incomplete rather than quietly omitted.
Questions we hear most.
An AuditProof is a signed, hash-chained proof that data was destroyed through a specific sequence of operations. Each destruction step is cryptographically linked to the previous, forming a tamper-evident chain. The proof is signed with an ephemeral Ed25519 key that self-destructs after signing. Anyone can verify it offline without trusting Nanorix.
A deletion log says “we ran a delete command at this time,” and you either believe the party who wrote it or you don’t. An AuditProof records that each destruction step executed, in order, with the step’s own method named — including the destruction of the capsule’s key material — and binds that record into a hash chain that cannot be edited without breaking it. The record is signed by a separate long-term key whose public half we publish, so anyone can check it without asking us. A log asks for your trust. An AuditProof asks you to check instead.
Your existing pipeline runs inside a sealed ephemeral capsule with multiple isolation layers. It works in a memory-backed filesystem with swap switched off at the cgroup, so your data is never written to persistent storage by us. When the capsule is destroyed, a multi-step destruction sequence executes and is recorded step by step. What survives is the AuditProof describing what happened — and if the sequence does not complete, the AuditProof says so rather than going missing.
Yes, and you do not have to take our word for how. The format is published as an open specification with four reference verifiers under Apache-2.0, archived with a citable DOI: 10.5281/zenodo.21901019 · github.com/nanorix-io/nanorix-verify. None of the four contains an HTTP client, so offline verification follows from the code rather than from a promise we make about it. They agree on a published corpus of 100 cases, including the tampered ones a verifier is supposed to reject. We run a verification endpoint for convenience; you never need it, and you never need us.
No. Your privacy platform manages workflows, consent, and DSARs. Nanorix generates the cryptographic proof that destruction actually happened. The AuditProof is the receipt your existing platform doesn't produce.
Every AuditProof includes a regulatory reference map showing which provisions each destruction step relates to. This covers HIPAA, SOC 2, GDPR, and other frameworks based on your declared jurisdiction. This is a factual mapping, not a compliance certification — your legal and compliance team makes the compliance determination.
Yes. An AuditProof is a self-contained, cryptographically signed artifact. Each step in the destruction chain is individually verifiable with standard tools (SHA-512, Ed25519). The regulatory context map shows your auditor exactly which HIPAA, SOC 2, or GDPR provisions each step relates to. The auditor can verify the proof independently — no dependency on Nanorix.
Most teams add Nanorix to their pipeline in under an hour. Two SDK calls: create a capsule and destroy it. Your code runs inside the sealed environment between those calls. You get back a signed AuditProof. SDKs are available for Python and TypeScript. The typical integration is under 15 lines of code.
Don't see your question?
Ask us anything. We typically respond within a few hours.