How SnapEnv actually protects your secrets
Not vague security-marketing language — the real mechanisms, so you can evaluate them yourself.
Encryption
Every variable value is encrypted with AES-256-GCM before it’s written to PostgreSQL. No plaintext value is ever stored.
Key management
Each project gets its own encryption key, derived via HKDF-SHA256 from a server-side master key (salt = project ID). The master key lives only on the API server — never in the database, never sent to the CLI, never logged.
Decryption
Server-side only. The CLI, operator, and API clients never handle a master key or derive keys themselves — they authenticate, and the server decrypts on their behalf within the scope their token allows.
Authentication
Two credential types: short-lived JWTs for web dashboard sessions, and snp_live_ access tokens for the CLI, operator, CI, and automation. Access tokens are stored as bcrypt(sha256(plaintext)) — the plaintext is shown once at creation and never recoverable again.
Access control
Three layers, all enforced server-side: workspace role (Owner/Member), project role (Admin/Developer/Read-only), and per-environment overrides (none/read/write). Protected environments — production, by default — give developers no default access until explicitly granted.
Audit logging
Every pull, push, variable change, and team action is recorded in an append-only log. Rows are never updated or deleted — the code path that writes them has no update or delete path at all.
Webhook signing
Webhook payloads are signed with HMAC-SHA256 using a per-webhook signing secret, so receivers can verify a payload actually came from SnapEnv.
Two-factor authentication
TOTP-based 2FA (RFC 6238), compatible with any standard authenticator app — Google Authenticator, Authy, 1Password, and others.
SnapEnv's architecture is designed with these controls in mind. We don't claim a specific compliance certification (SOC 2, etc.) unless and until it's actually completed — happy to answer specific security-review questions directly at security@snapenv.io.
Does SnapEnv store plaintext secrets?
No. Every value is encrypted with AES-256-GCM before it is written to the database. Decryption happens server-side only, in response to an authorized request.
How are SnapEnv encryption keys managed?
Each project has its own encryption key, derived via HKDF-SHA256 from a server-side master key. The master key never lives in the database and is never sent to the CLI, operator, or any client.
Is SnapEnv SOC 2 certified?
SnapEnv's architecture is designed with these controls in mind, but we don't claim a specific compliance certification unless and until it's actually completed. Contact us directly for specific security-review questions.
How does SnapEnv verify webhook payloads are authentic?
Webhook payloads are signed with HMAC-SHA256 using a per-webhook signing secret. Receivers compute the same signature over the raw request body and compare it to the X-SnapEnv-Signature header.
Try SnapEnv free
3 projects, 3 members, full CLI & Kubernetes operator. No credit card.