Distributed object storage
Tessera encrypts your data on your machine, splits it into 30 shards, and distributes them across 30 independent storage providers. Any 10 rebuild the file. Your bytes never pass through our servers.
Upload · Download · Store · One HTTP API
Clients
One signed HTTP API underneath all of it. Pick the surface that fits your workflow — a CLI for scripts and servers, a desktop app for a folder you drag files into, or a browser for everything else.
Command line
A static binary for syncing folders, scripting uploads, and driving Tessera from a server or a CI job.
curl -fsSL https://raw.githubusercontent.com/TesseraStorage/tessera-cli/main/install.sh | bashPrefer a binary? Download it manually
Desktop app
A folder on your machine that syncs to Tessera in the background — no terminal required.
Browser
Upload, browse, and share files from any browser, no install. No downloads — just sign in and go.
Launching soon
The premise
Conventional object storage replicates your data inside one company's infrastructure. If that company suffers a catastrophic failure, deletes your account, or simply ceases to exist, every replica shares the same fate — because every replica shares the same owner. Tessera removes the shared owner.
What Tessera never receives
What Tessera does hold
This is the whole design. We operate the parts that need coordinating — provider selection, contracts, placement records, repair — and stay out of the parts that need trusting. Read the full trust model →
How it works
You call one API. Underneath, an object becomes 30 encrypted fragments held by 30 unrelated businesses, and stays that way for as long as you keep paying — with the arithmetic to survive two-thirds of them disappearing.
Your client encrypts the object before a single byte is transmitted. Providers receive ciphertext and nothing else.
Client-side · symmetric encryption
Reed–Solomon erasure coding produces 10 data shards and 20 parity shards. Any 10 of them reconstruct the original.
10+20 · 3.0× storage overhead
Each shard goes to a different provider, selected from a continuously vetted pool. No provider ever holds more than one shard of a slab, so none of them holds anything reconstructable.
One shard per provider, enforced
We scan shard health continuously. When a provider disappears, its shards are rebuilt from parity onto fresh providers — without you asking, and without a read.
Continuous · automatic
Your machine
Encryption and erasure coding happen here. Nothing leaves in a readable form.
Direct transfer
Shards move straight from your client to each provider over an authenticated session. Tessera is not in the data path.
30 independent providers
One shard each. No provider ever receives a second shard of the same slab.
Tessera control plane — alongside, not in between
The network underneath
Durability
Erasure coding replaces the copy-everything model with arithmetic. Drag the slider: take providers offline and watch what it costs you. Up to 20, the answer is nothing.
Reed–Solomon 10+20
Fully recoverable
27 shards remain — 10 is the minimum. Your file reconstructs with no loss and no user action.
Tolerance — any 20 of 30 providers may fail simultaneously with zero data loss. Solid tiles are data shards, outlined tiles are parity.
Losing an object requires 21 of 30 unaffiliated providers — different companies, different hardware, different jurisdictions — to fail inside a single repair window.
A single operator outage, a regional power event, or one company going bankrupt takes down a fraction of your shards, not a replica set that shares an owner.
Every shard is addressed by its Merkle root. A provider that returns altered bytes is detected on read, rejected, and repaired — silent corruption cannot propagate.
What we will not claim
Survivability
Most providers ask you to assume they will still be here. We would rather remove the assumption. Our contracts are funded far ahead of need, and the information required to retrieve your data without us is yours to hold.
60days
Storage contracts are funded roughly 12 weeks ahead of need — we deliberately overpay. If Tessera went dark permanently and no one renewed anything, your shards would remain retrievable from providers for at least 60 days. That is not a support commitment; it is a consequence of money already spent.
0middlemen
Reads already go client-to-provider. Given the placement record for an object — which providers, which shard roots, which parameters — a client fetches and rebuilds it directly. Our API is the convenient way to look that up, not the only way to use it.
1export
Every object's placement is readable through the API at any time. Export it, store it with your own backups, and your recovery path no longer depends on our continued existence. We recommend doing this on a schedule.
The honest framing: we are a convenience layer over a market, not the vault. Losing us should cost you an integration, not an archive.
Security & compliance
Our control plane runs on dedicated hardware in Germany, in an ISO/IEC 27001-certified facility. That certificate covers the building and the network, not us. Everything else below is self-assessed, and every item says which is which — because a compliance page that blurs the difference is not worth reading.
Scope · Hosting facility and network (Hetzner Online GmbH)
Hetzner Online GmbH, which provides the dedicated hardware and the data centre the Tessera control plane runs in, operates an information security management system certified to ISO/IEC 27001:2022 by SOCOTEC Certification Deutschland GmbH, with a scope covering all of its hosting services and data centres. Because we run bare metal rather than a managed cloud, what this covers is narrow: the facility, physical access, power, cooling, and network. It says nothing about the operating system upwards, which is ours. Certification of the Tessera entity itself is on the roadmap.
Evidence: Hetzner Online GmbH ISO/IEC 27001:2022 certificate — published by the provider
Scope · Tessera as data processor
Tessera acts as a processor for customer content and as a controller for account and billing records. Data protection agreement, records of processing, subprocessor disclosure, and data-subject request handling are in place and self-assessed. No third-party GDPR audit has been performed.
Evidence: DPA available on request · subprocessor list published
Scope · Tessera service
Cloud Security Alliance Consensus Assessments Initiative Questionnaire completed as a self-assessment against the Cloud Controls Matrix v4. This is a Level 1 self-attestation, not a third-party (Level 2) certification.
Evidence: Completed CAIQ workbook — available on request
Scope · API and web surface — Level 2 target
The Application Security Verification Standard is used as the internal engineering checklist for the API surface. We target Level 2. Verification is internal; there is no external ASVS attestation and no independent penetration test has been completed yet.
Evidence: Internal control mapping
Scope · Organisation-wide
Security programme structured against the six NIST Cybersecurity Framework 2.0 functions — Govern, Identify, Protect, Detect, Respond, Recover. Current-profile self-assessment maintained internally with a documented target profile.
Evidence: Current and target profile worksheets
Scope · Implementation Group 1, moving to IG2
CIS Critical Security Controls are used for operational hardening baselines — asset inventory, secure configuration, access control management, audit log management, and incident response. Self-assessed at IG1 with IG2 safeguards in progress.
Evidence: CIS-CAT self-assessment worksheet
For developers
Provision a credential, ask for placement, write your shards, record the object. Requests are authenticated with an ed25519 signature you can produce in any language — there is no session, no cookie, and no proprietary client you are obliged to use.
# 1 — provision a credential
curl -X POST https://api.PLACEHOLDER_DOMAIN.example/auth/provision
# 2 — ask for placement: 30 providers, 10-of-30 geometry
curl -X POST "https://api.PLACEHOLDER_DOMAIN.example/prepare-write?$AUTH" \
-d '{"totalShards": 30, "minShards": 10}'
# 3 — encrypt, erasure-code, and write shards to the returned providers
# 4 — record placement
curl -X POST "https://api.PLACEHOLDER_DOMAIN.example/slabs?$AUTH" -d @slab.json
curl -X POST "https://api.PLACEHOLDER_DOMAIN.example/objects?$AUTH" -d @object.jsonSigned requests, no sessions
Every call carries an ed25519 signature over the method, host, path, expiry, and body. Nothing to store, nothing to refresh, nothing to steal from a cookie jar.
Erasure geometry is yours to set
Ten-of-thirty is the default. You can widen it per slab, within a validated range, when a workload deserves more parity.
Revocation is immediate
Credentials can be revoked in one call. Access stops at the next request — there is no token lifetime to wait out.
Opaque metadata by design
Filenames and structure live in a blob only your keys can interpret. If you want a directory tree, you build it — we cannot read it either way.
A credential takes one request. The first object takes about fifteen minutes.