When not to use Lockwell
Most storage products tell you what they can do. This page is the other half, kept deliberately on the front of the site: what Lockwell refuses to do, and what to use when a refusal rules it out. Every entry here is enforced by the server (refused operations fail closed with an error; nothing is silently dropped or half-implemented) and pinned by tests in the repository, so this list cannot quietly drift out of date.
Do not use Lockwell if you need…
Public buckets or anonymous access
Lockwell is private-only. There are no public buckets, no anonymous reads, no public website hosting, and no unauthenticated presigned POST uploads. Every request is authenticated against a tenant-scoped key or a signed URL minted from one. Note what this does NOT rule out: sharing. An expiring signed link (a 7-day client download, a one-hour browser upload) carries its own permission, so the recipient needs no account and no key, and the link dies on schedule. What is refused is the permanent, unauthenticated, world-readable path. If your workload truly is "host these images for the open internet", put a CDN in front of a public-object store instead: Cloudflare R2, Backblaze B2, or S3 with CloudFront. Lockwell can still hold the private originals behind it.
A multi-node, replicated cluster
The documented default is single-node: one process, one store directory, the embedded metadata engine. An opt-in Raft consensus mode ([cluster.consensus]) replicates metadata and object placement across a three-node cluster, and it passes a live acceptance gate with fault injection on CI hardware — but it is not yet an approved release profile, so its gate fails closed until the remaining replicated-durability evidence lands. There is no erasure coding and no multi-AZ failover in either mode. Single-node durability comes from per-commit or grouped fsync, always-on at-rest encryption, scrub/repair, and backup/restore drills, proven by the crash-takeover and disaster drills in the release gates.
Status, honestly: consensus replication is implemented opt-in and exercised live, but the replicated deployment claim stays behind the same release gates everything else passed; until that day, plan for single-node. Note that bucket-level S3 replication (?replication) is a different, already-shipped feature — it copies objects between same-tenant buckets inside one deployment and does not provide multi-machine failover. If you need a cluster that survives the loss of a whole machine without a restore today, use a replicated system: S3, R2, B2, or self-hosted Ceph RGW or Garage on multiple nodes. Teams that want Lockwell anyway run a warm standby meanwhile: a second instance fed by scheduled S3-level sync, with restore drills proving the seam.
AWS IAM, STS, or KMS
Lockwell does not implement IAM policies, STS temporary credentials, or SSE-KMS. Access control is tenant-scoped access keys with read/write/delete/admin flags and optional bucket scoping; encryption is always-on at rest with per-tenant data keys. A request for SSE-KMS is refused rather than faked: Lockwell will not accept a KMS header, store the object under its own keys, and let your compliance audit believe a KMS was involved. SSE-C (your key, per request) is supported.
Provider-native event buses and analytics
Bucket notifications deliver to webhooks with constant-time HMAC signatures. There is no delivery to SNS, SQS, or Lambda. S3 Select, S3 Tables, S3 Vectors, Object Lambda, and Express directory buckets are permanent non-goals. If your pipeline is built on those, stay on AWS for those buckets.
Remote storage backends
Objects live on the local filesystem of the node, encrypted. In-store storage classes are implemented: writes accept x-amz-storage-class across the archival classes (GLACIER, DEEP_ARCHIVE, and the warm tiers), lifecycle rules transition versions to an archival class, an Intelligent-Tiering configuration moves versions between access tiers by no-access age, and a RestoreObject window reopens archived reads — all inside the same encrypted store. What is still absent is a remote medium: there is no tiering to an external cold store and no S3-as-backend proxy mode. There is also no shipping Xet storage engine, Xet protocol compatibility, xorbs, shards, caches, or global deduplication. A detached content-defined-chunking evaluation matched the published Xet gear table and fixture, but its attempted unpacked writer was rejected after review found descriptor use could grow with chunk count. It has no public configuration, production write path, SDK behavior, recovery evidence, or demonstrated performance/storage benefit. Datasets that cannot fit one machine's disks are out of scope (see the cluster row above).
What "fail closed" means here
An S3 call outside the documented surface returns an explicit error instead of pretending to succeed. The parity ledger documents every operation and its exact behavior; the compatibility contract names the workloads where Lockwell is a candidate replacement, and the workloads where it is not. Both are enforced by sync tests, so the docs and the server cannot disagree for long.
When Lockwell is the right choice
The honest inverse, briefly: private S3 object storage for authenticated SDK/CLI clients; encrypted tenant-scoped backup or artifact storage; compliance-oriented internal S3 where audit, retention, legal hold, and operator recovery matter more than broad AWS feature parity; and the whole storage layer of a multi-tenant app via the app kit: provisioning, scoped keys, signed browser uploads, verified webhooks, one SDK.
If you are migrating from MinIO or Garage, run lockwell migration s3 plan first: it refuses blocked source features instead of silently dropping them, and only reviewed plans execute.
Deeper: Getting started · The three surfaces · Tenancy & auth.