We are opening a design partner program. See the program
DEVELOPERS
One client-side encryption SDK, in TypeScript: install it, point it at the object storage you already run, ship. Encryption, dispersion, and public anchoring happen behind a clean API, so none of it is code you write, own, or defend in a security review. Your users just see files.
QUICKSTART
Initialize a client, create a project, upload a file, read it back. Everything below the API line, key derivation, chunking, erasure coding, anchoring, is code you never write, test, or keep patched. And when your security review asks what is actually inside those calls, the next section is the answer.
import { readFile } from "node:fs/promises";
import { DataPrismKey, DEFAULT_ENCRYPTION } from "@dataprism/sdk/crypto";
import { CloudStandard } from "@dataprism/sdk/standard";
import { FilePipeline } from "@dataprism/sdk/files";
// Client, providers, project and key secret, one config file in your project:
// docs.dataprism.co/sdk/client
import { client, providers, project, secret } from "./dataprism";
// Create a project: an encrypted namespace you control
const key = DataPrismKey.fromSecret(secret, DEFAULT_ENCRYPTION);
const standard = new CloudStandard(key);
const { cloudId } = await client.prism(standard).create(project);
// Upload: encrypted on this machine, dispersed with redundancy,
// integrity anchored on a public registry
const bytes = await readFile("contract.pdf");
const pipeline = new FilePipeline({
standard,
execution: client.execution,
cloudId,
providers,
});
const { index } = await pipeline.upload("contract.pdf", bytes, {
chunkSize: 65_536,
dataShards: 7,
parityShards: 3,
});
// Download: shards fetched in parallel, reconstructed from any
// quorum, decrypted locally
const restored = await pipeline.download(index);UNDER THE HOOD
Before you ship an encryption layer, someone on your side will ask exactly what leaves the machine, and what happens when a provider fails. Here is the pipeline behind upload(), stage by stage, with a link to the docs page that carries the full detail of each. Enough to answer that review without reading our source.
Edit a large file and re-upload it, and only the parts that actually changed travel again: files are cut at natural content boundaries, not fixed offsets, so one insertion does not re-slice everything after it. You get delta-sized re-uploads without maintaining a diff format of your own.
Chunking, in the file pipeline docsEvery chunk is encrypted on your machine before anything leaves it, so there is no key service to stand up and nothing to escrow. The derivation is deterministic, so unchanged content is recognised as already stored: a re-upload moves only what actually changed, and identical content occupies your storage once rather than once per copy.
Convergent encryption, in the file pipeline docsEncrypted chunks are expanded with redundancy you choose and dispersed across the independent providers you configured, so a provider outage, or a provider dropping your account, stays a non-event up to that redundancy. No failover path of your own to write, rehearse, and keep in sync.
Erasure coding, in the file pipeline docsWhat gets anchored is a constant-size encrypted index, whatever the file size, and its integrity does not rest on any operator, including us: reads reconstruct your data from any quorum of fragments and decrypt locally. Showing that a file was not altered is then a check the asker runs, not an endpoint you have to build and support.
Prisms and anchoring, in the docsWhen a customer or a regulator asks whether erased really means erased, you can point to a documented lifecycle instead of a dashboard checkbox: deletion is specified in the SDK reference to enumerate every fragment a file left behind, remove each one at its provider, and report anything that failed, provider by provider. That is a reconciliation job you do not have to write and own.
The deletion lifecycle, in the SDK referenceHOW THE SDK THINKS
KEYS STAY WITH YOU
Chunk keys are derived from the content itself, which is what makes re-uploading unchanged data cheap. The index that assembles them is sealed with a key derived from a secret you control, and neither key is ever sent to us: everything the SDK sends outward is already encrypted. Adding a provider never widens what anyone can read.
What each actor can and cannot see is laid out in our verifiable security architecture.
INVISIBLE TO USERS
No cryptographic plumbing is ever exposed to your users. Keys and execution stay behind your product's own login and UI, so there is no new step in your onboarding and nothing extra for your support team to answer. To them, it is just storage that happens to be unreadable to everyone else.
DOCUMENTED END TO END
Every layer is documented in the open at docs.dataprism.co: the SDK reference, the file pipeline, the contracts, runnable Node.js and Next.js examples. If you can read a README, you can evaluate us before you ever talk to sales.
INTEGRATION TARGETS
No new storage vendor to onboard, no infrastructure migration, no protocol to learn: wherever the fragments land, the pipeline behind the SDK stays the same. Adding or dropping a provider is a config change, not a project.
The buckets you already operate become dispersal targets for encrypted fragments.
An independent provider that widens the dispersal set.
European object storage as an independent dispersal target.
Object storage you run yourself joins the same set.
This page shows the shape of the system. The docs go all the way down: the full SDK reference, the pipeline internals, and runnable Node.js and Next.js examples.