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 embedded metadata engine is single-node by design in v1. There is no multi-node replication, no erasure coding, and no multi-AZ failover; the replicated deployment profile is suspended and its release gate fails closed. Durability comes from per-commit or grouped fsync, always-on at-rest encryption, scrub/repair, and backup/restore drills. The crash-takeover and disaster drills that prove them are part of the release gates.
Status, honestly: replication is deferred, not denied. It is in design, and it ships only when it passes the same takeover and durability drills everything else passed; until that day the server says no. 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.
Storage tiering or remote backends
Objects live on the local filesystem of the node, encrypted. There is no tiering to cold storage and no S3-as-backend proxy mode. 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.