How the encryption works

  • The proxy uses AES-256-GCM with a per-object IV and applies it after delta compression.
  • There are four modes, set per backend: none, aes256-gcm-proxy, sse-kms, sse-s3. We don't support SSE-C.
  • In proxy-AES mode you supply the key per backend, as an env var or a ${env:...} reference, and the proxy strips it from config exports. The backend (AWS S3, Hetzner, MinIO, etc.) sees only ciphertext.
  • Proxy-AES needs a backend with atomic (conditional) writes, because the proxy rewrites encrypted objects in place. The proxy checks each backend with a probe. AWS S3, MinIO, Hetzner Object Storage and filesystem backends pass. Backblaze B2 does not, so there you use the backend's own encryption (SSE). How the check works.
  • Key rotation happens per backend and does not replace the old key in place. The old key stays as a decrypt-only shim while a background re-encrypt job rewrites historical objects. When the job finishes, you delete the old key. Reads and writes go on while the job runs: each rewrite is conditional on the version that the job read, so it never overwrites a client write.
  • A bucket holds one key. A second proxy that shares the backend but not the key cannot write into an encrypted bucket. It refuses the write, so nothing lands in plaintext or under another key next to your ciphertext.
  • Every S3 request lands in the structured stdout log. Proxy-AES mode does not emit per-decrypt audit events. If you need "who decrypted what, when", use sse-kms and read CloudTrail.

How key custody stays in your runtime

  • The proxy runs in your VPC, on your Kubernetes, or on your bare metal.
  • In proxy-AES mode, the encryption key never leaves the proxy process.
  • Backend credentials never leave the proxy process.
  • The users, groups, and SSO settings live in a SQLCipher database with its own key (DGP_CONFIG_DB_KEY, or a generated key file), separate from the admin password. A synced copy in a bucket is encrypted with the same key.
  • The proxy does not phone home, sends no telemetry, and has no SaaS dependency.
  • The source code is public (BUSL-1.1), so your security team can read every line.

What we don't claim

  • We don't claim "SOC 2 compliant". DeltaGlider produces audit logs you can ship into a SOC-2-attested SIEM. The proxy itself is software, not a compliance regime.
  • We don't claim "FIPS 140-3 validated". We use the RustCrypto aes-gcm crate for AES-256-GCM. If you need FIPS, ship the FIPS-validated crypto layer underneath us.
  • "GDPR-compliant" is also not ours to claim. DeltaGlider supports right-to-be-forgotten propagation through replication-delete and lifecycle expiration. We provide the technical controls; the compliance certification is yours to obtain.

How a regulated buyer evaluates DeltaGlider

In week 1, your security team reviews the code. The proxy's full source is public (BUSL-1.1). The encryption module is in src/storage/encrypting/, the IAM model in src/iam/, and the admin API surface in src/api/admin/. Send their questions to contact@beshu.tech.

In week 2, you deploy in a dev environment. Point a test bucket at the proxy and run your existing security automation against it (key rotation, audit log validation, an IdP integration smoke test).

In week 3, you run a small production pilot on one non-critical bucket.

In week 4, you write the full deployment plan with Beshu engineering support, which comes with the 30-day Commercial trial.

Talk to sales

Commercial contract terms are negotiable, including jurisdiction, audit requirements, and procurement workflow, so email us.

Email sales@beshu.tech Start with the 30-day trial