Envault prioritizes security above all else. Our architecture is designed to ensure that your secrets remain confidential, even in the event of a database compromise. We adhere to the principle of Defense in Depth.
Envault recently transitioned its Go CLI to a True Client-Side Encryption (CSE) model.
Unlike traditional architectures where the Node.js API server decrypts the payload and sends plaintext variables over the wire, Envault pushes the cryptographic heavy lifting to your local machine:
envault pull: The Next.js API provides the unwrapped Data Encryption Key (DEK) and the raw AES-256-GCM ciphertext to the Go CLI. The Go CLI performs the AES decryption locally on your machine.
envault deploy: The Go CLI requests the active DEK from the server, encrypts your local .env variables locally via AES-256-GCM, and transmits only the resulting ciphertexts to the Supabase database. The Node.js server never sees your plaintext secrets.
Impact: Critical.
If an attacker gains full shell access to the running server, they can read the ENCRYPTION_KEY from the environment.
Mitigation: Use a hardened infrastructure provider (e.g., Vercel, AWS ECS). Restrict access to the production environment. Envault does not store decrypted secrets on disk.
The attacker might have access to the local .env file if it was pulled.
Mitigation: envault pull does not persist credentials permanently. Revoke the user's access immediately via the dashboard to prevent fetching new secrets.