Ephemeral compute.Permanent proof.
A sealed environment for regulated data that runs in your own cloud. The data, the run and its signed record stay there, and nothing reaches us. Your workflow stays the same. Nothing persists — architecturally, not by policy.
The environment disappears. The evidence remains.
Production runs in your cloud · Free hosted Evaluation Sandbox for synthetic data · No credit card
What a capsule produces.
A signed, timestamped record of what happened — independently verifiable. Your compliance team maps it to their frameworks. Your auditor checks it.
A signed record of the environment the capsule was configured with, what the runtime recorded during execution, and whether destruction completed. Every step chained to the last, and one signature over all of it. Tamper-evident by construction.
Every framework listed asks for the same kind of evidence — isolation, processing integrity, verified destruction. One artifact. Whether it is acceptable evidence for a given control is your compliance team’s and 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.
One call wraps 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 client = nanorix.Client(api_key="nrx_live_...") # Create a capsule, upload, run, download, destroy outputs, proof = client.capsules.run( capsulefile="cf_...", inputs={"records.csv": open("records.csv", "rb")}, ) # The signed AuditProof for the whole run auditproof = proof.full()
import { readFileSync } from 'node:fs'; import { NanorixClient } from '@nanorix/sdk'; const client = new NanorixClient({ apiKey: 'nrx_live_...' }); // Create a capsule, upload, run, download, destroy const [outputs, proof] = await client.capsules.run({ capsulefile: 'cf_...', inputs: { 'records.csv': readFileSync('records.csv') }, }); // The signed AuditProof for the whole run const auditproof = proof.full();
# Create a capsule POST /v1/capsules Authorization: Bearer nrx_live_... Content-Type: application/json { "data_classification": "PII", "capsulefile_id": "cf_..." } # Upload data POST /v1/capsules/{id}/upload Content-Type: multipart/form-data # Run your code POST /v1/capsules/{id}/exec # Download the results GET /v1/capsules/{id}/output/{filename} # Destroy and get the AuditProof DELETE /v1/capsules/{id} # Response (abridged) { "status": "destroyed", "cdp": { ... }, "verification_cdp": { ... }, "regulatory_context": { ... } }
Production runs in your cloud.
Evaluate free in the hosted Evaluation Sandbox with synthetic data, then run production in your own cloud. On every plan, a capsule whose destruction completes produces a signed, independently verifiable AuditProof, and a destroy you call that stops partway returns a signed record identifying the step where it stopped rather than quietly returning nothing.
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 chain records the destruction of the capsule’s own keys, and the sealed chain is then signed by the deployment’s signing authority — a KMS-held Ed25519 key whose public half is published. 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 a destroy you call stops partway, its response carries a signed record identifying the step where it stopped 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.
A completed destroy call returns a regulatory reference map alongside the AuditProof, 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.
In code, one SDK call: capsules.run creates a capsule, uploads your inputs, runs your code inside the sealed environment, downloads the outputs and destroys the capsule, and you get back the signed AuditProof. Over REST the steps are the same: create, upload, exec, download the outputs, destroy. SDKs are available for Python and TypeScript, and the REST API works from any language. For production, the Helm chart installs Nanorix on your own Kubernetes cluster with your own Postgres, and an engineer scopes that install with you.
Don't see your question?
Ask us anything. We typically respond within a few hours.