S3-compatible storagefor records.One process. One server.
Record Store is a self-hosted storage service, written in Rust, for files that need version history, retention controls and verifiable integrity. No external database, no message broker, no coordination service alongside it. Your applications keep the AWS SDK they already use — you change the endpoint.
Production images for linux/amd64 and linux/arm64 are published to the GitHub Container Registry. Both packages are public — no docker login.
Record Store ships with no built-in credentials. Put the root key pair, the credential master key and the management token in .env, and it starts.
Every release also ships Debian and RPM packages, a Helm chart and statically linked binaries. Run record-store server doctor first — it checks the machine without starting anything.
git clone https://github.com/OpenElementsLabs/record-store.git
cd record-store
RECORD_STORE_VERSION=0.2.1 docker compose \
--env-file .env -f deploy/docker/compose.ghcr.yml up -d
7600
S3 API, also serves embeds
7601
Management API, keep it private
7602
Web console and share pages
Every listener is configurable. Objects live under one data directory as ordinary files — back it up the way you back up everything else.
What Record Store does
The S3 surface your SDK expects
SigV4 header auth and presigned GET/PUT, streaming objects, ListObjectsV2 with pagination, multipart uploads, bucket versioning with delete markers, per-bucket CORS, CopyObject, byte ranges and conditional headers. Every body digest a client sends — Content-MD5, CRC32, CRC32C, SHA-1, SHA-256 — is verified, and a mismatch stores nothing.
Object Lock, with AWS semantics
GOVERNANCE and COMPLIANCE retention, legal holds and per-bucket default retention. A compliance retention can only be extended — not shortened or removed, not even by root. A governance bypass needs its own permission, and every attempt is audited.
Integrity you can verify offline
Checksums on write and on read: a damaged payload fails the read instead of completing as a download. For any object version, record-store verify object emits a signed proof bundle that anyone can check against the file with no server, network or credential.
Checked against the real clients
Compatibility runs against boto3, the AWS SDK for JavaScript v3, the AWS SDK for Go and the AWS SDK for Java v2 on a live server — bucket and object I/O, listing, multipart completion, presigned requests, browser CORS, ranges, versioning and copy behaviour.
Credentials, policies and an audit trail
Service accounts with rotatable credentials, allow/deny policies where explicit deny wins, temporary credentials, and management roles held separately from S3 access. Every change is audited and exportable for auditors; storage events go out as HMAC-signed webhooks, delivered at least once.
Encryption at rest, under your key
Chunked AES-256-GCM with a per-object data key wrapped by a master key you supply and control. Record Store never stores that key, and refuses to start rather than making encrypted data silently unreadable.
Share links and embeds, not credentials
A share link gives a person read access to one object through a Record Store page; an embed link gives a site a read-only URL for the bytes. Both are revocable capabilities that name exactly one object — they can never list, write or delete.
What it does not do
Being precise about this is more useful than a longer feature list.
A deployment is one process with one copy of your data. Replication and erasure coding are not implemented, and if the machine is gone the service is down until you restore it. Durability is whatever the storage underneath it gives you — use redundant disks, and take backups with record-store server backup, which needs the server stopped.
Object Lock is enforced by Record Store, not by the filesystem: it stops deletions through the API, not someone with access to the data directory. A proof bundle is signed with a key derived from the deployment's own master key, so it is evidence against alteration in transit, not against the operator. The tamper-evident audit chain is still in development.
ACLs, UploadPartCopy, server-side encryption headers, AWS's aws-chunked trailing checksums and CRC64NVME checksums are not implemented. Unsupported operations return an S3 NotImplemented error — they are never silently accepted.
Browser uploads through the console are not resumable. An interrupted upload has to be sent again from the first byte, and the console says so instead of implying otherwise.
Client code
Point the endpoint at 7600. That is the integration.
Use path-style addressing and any credential the deployment authorises. Guides for JavaScript, Next.js, Python, Go, Java and Rust are in the documentation.