parstore

S3-compatibleencrypteddistributed

Storage that no single hoster owns.

parstore encrypts every file, splits it into fragments and spreads them across independent hosters, data centres and countries. If a hoster fails, locks your account or goes bust, your data stays readable. Steal a single store and all you get is encrypted debris.

How it works See the features
  • 4+2two hosters may fail at the same time
  • 1.5×storage instead of 3× with copies
  • AES-256GCM, its own key for every chunk
A file split into six fragments An encrypted file is split into four data and two parity fragments. Each fragment is stored with a different hoster in a different country. One hoster has failed; the file is still readable from the remaining fragments. File encrypted D1 D2 D3 D4 P1 P2 DEHoster A ATHoster B NLHoster C FRHoster D PLHoster E FIHoster F Readable: 5 of 6 reachable, 4 are enough

How it works

Mathematics instead of copies.

A full copy at a second provider doubles the cost and protects against exactly one failure. parstore uses Reed-Solomon codes: any k of k+m fragments restore the whole file. With 4+2, a file survives two hoster failures at the same time with 1.5 times the storage.

  1. Encrypt

    Every chunk is encrypted with its own key (AES-256-GCM) before it leaves the gateway. No hoster ever sees plaintext or a key.

  2. Split

    The encrypted content is split into k data fragments, and m parity fragments are added.

  3. Spread

    Each fragment goes to a different hoster, data centre or country. A write is acknowledged only once its protection target is met.

  4. Restore

    Any k fragments are enough to read. If one is missing, it is rebuilt in the background and stored elsewhere.

contract-2026.pdfEncrypted · coding 4+2 · 1.5× storage
  • Data fragment
  • Parity fragment
  • D1
    Hoster AGermany
    reachable
  • D2
    Hoster BAustria
    reachable
  • D3
    Hoster CNetherlands
    down
  • D4
    Hoster DFrance
    down
  • P1
    Hoster EPoland
    reachable
  • P2
    own VMFinland
    reachable

File still readable. 4 of 6 fragments reachable, 4 are needed. In the background parstore rebuilds the missing fragments and stores them with other hosters.

Features

Storage that looks after itself.

From the outside, ordinary S3 storage. On the inside, a system that repairs failures by itself and weighs cost, speed and resilience against each other, always with safety first.

S3-compatible

SigV4, multipart, range reads, conditional requests and the checksums of current SDKs. Tested with the AWS SDK and the aws-cli. Clients connect through a load balancer with failover.

Self-healing

Missing or damaged fragments are rebuilt from the others. A scrubber keeps checking checksums without needing any keys.

Snapshots and deduplication

Scheduled bucket snapshots with retention rules; restore a file, a folder or a whole bucket. Identical content within a customer is stored only once.

File area in the browser

Folders, uploads, previews, search, versions and a trash. Share links with password and expiry, file requests for outsiders, personal spaces and retention rules.

Desktop client with drives

Buckets as a drive or folder on Windows, macOS and Linux. Sign-in through the browser, separate access keys per device, automatic updates.

Backups to and from your servers

Copies of buckets to SFTP, FTP(S) or S3 servers with a dated versions folder, and backups of such servers into parstore. On signs of an attack a run stops and waits for approval.

Data residency

Hoster, country and location count as separate failure domains. Per customer you decide in which countries fragments may be stored, for example only in the EU.

Cost optimisation

Purchase prices per backend, reads from cheap fragments first, and a simulation of which backends can be emptied, with the monthly saving and the one-off move cost.

Start small, grow without rebuilding

Start on one server. Further servers join and replicate the metadata over Raft; every server is a gateway. Updates roll out one server at a time, re-encoding runs in the background.

Recovery from the backends

The metadata is backed up regularly, encrypted and erasure-coded across several backends. With the recovery kit, a new instance is restored from it.

Tenants and billing

Customers with their own portal, team, quotas and access keys. Storage, traffic and requests are recorded hourly per customer and bucket; purchase and sales prices with margin warnings.

API first

Everything the interface can do also works through a self-documenting API with examples. Dangerous actions come with a dry run, confirmation and an audit entry.

Security

A stolen store is worthless.

Encryption happens before splitting. A single hoster holds only encrypted fragments without names or context, and never more of them than may be lost.

  • A key per chunk

    AES-256-GCM with its own key for every chunk. Bucket and tenant keys stay in the management, never with a hoster.

  • Verifiable without keys

    Every fragment carries a checksum and a MAC. Scrubbing finds and repairs damage without ever producing plaintext.

  • No ack without protection

    A write is acknowledged only once it is spread according to the rule of its storage class. Tests check this on every build.

  • Two factors, always

    Mandatory 2FA with TOTP, roles, session management, Argon2id for passwords and an audit log for every change.

  • Key export

    Root and recovery keys can be exported with a passphrase and a fresh second factor, and the export can be test-restored in advance.

  • Deleting with a safety net

    Destructive actions have a dry run and a delay: a trash for files, a restore period for buckets and customers.

Who it's for

For everyone who does not want to depend on one provider.

Good fit

  • Self-hosting on mixed infrastructure of VMs, managed S3 and own servers
  • Small and medium-sized businesses that want to survive the failure of a hoster
  • Backups, archives and media collections up to very large files
  • Teams that need a file area with share links for staff and outsiders
  • Providers who want to pass storage on to their own customers
  • Anyone who wants to start small on one server and distribute later

Less of a fit

  • Databases with very many small, latency-critical writes
  • Requirements that already call for ISO 27001, BSI C5 or a contractual SLA today
  • Anyone simply looking for the cheapest single bucket
  • Expecting the resilience of a distributed system from a single server

parstore is a young product in its lab phase. Further access protocols such as SFTP, WebDAV, NFS and SMB are planned.