Working with encrypted env files

Dotvault has first-class support for Laravel’s encrypted env file format. You can open, edit, encrypt, decrypt, and rotate keys on .env*.encrypted files entirely from inside the app — no PHP, no artisan env:decrypt, no temporary plaintext copies sitting on disk waiting to embarrass you.

Supported formats

Dotvault implements Laravel’s encryption natively in the main process, using AES-256-CBC and AES-128-CBC with HMAC-SHA256 verification. Both Laravel sub-formats are supported:

Standard. The entire file is encrypted as a single payload.
Readable. Variable names are visible; each value is encrypted individually.

The format is detected automatically when you open a file, and the base64: key prefix Laravel uses is handled for you. You can convert between Standard and Readable from the encryption settings in the editor.

Opening an existing encrypted file

Dotvault detects .env*.encrypted files in your project and marks them in the sidebar. Click one and you’ll be prompted to paste the encryption key. Once the key is accepted:

The file is decrypted in memory.
Dotvault stores the key securely, scoped to that file’s absolute path.
You get the normal editor — edit variables, add sections, run sync — exactly as you would with a plaintext file.
Saving re-encrypts the file automatically before writing it back to disk.

You only paste the key once per file per machine. Every subsequent open is transparent.

Encrypting a plaintext file

To encrypt a file that isn’t encrypted yet, use the Encrypt button in the editor toolbar, or right-click the file in the sidebar and pick Encrypt. Dotvault generates a key for you, stores it, and writes the encrypted file alongside the original. It’ll also offer to stage the .env*.encrypted file in git for you.

Mislabelled files

Dotvault notices when a file’s name and its actual contents don’t match. If a file is named .env.encrypted but actually contains plaintext (or vice versa), you’ll get a warning. The detector is tri-state — encrypted, mislabelled, or plaintext — and uses both the filename pattern and a content sniff, so it won’t be fooled by a rename alone.

Path-scoped keys

Encryption keys in Dotvault are scoped to the absolute path of the encrypted file. That means:

Two different encrypted files in two different projects have two completely independent keys.
Keys are encrypted at rest using safeStorage and never leave the main process in plaintext.
Keys survive the file being removed and re-added inside Dotvault.

If you rename an encrypted file, always do it from inside Dotvault — right-click the file and pick Rename. Dotvault atomically renames the file on disk and migrates the keychain entry along with it, so you don’t have to paste the key again. If you rename the file outside Dotvault, the keychain entry is orphaned; Dotvault will prompt you for the key the next time you open the renamed file, and it tidies up the orphaned entry automatically on the next launch.

Rotating keys

If you suspect a key has leaked — or you saved it somewhere you shouldn’t have — use Rotate key. Dotvault generates a new key, re-encrypts the file’s contents with it, and replaces the stored key. Save the new key somewhere safe (a password manager) immediately: Dotvault deliberately never shows the key again after first save.

If you’ve lost both the Dotvault keychain entry and any external copy, the file is unrecoverable. That’s how encryption is supposed to work.

Commit the .env*.encrypted file to git. Share the key through your password manager — never in chat, never in email, never in the repo itself. Each teammate opens the file in Dotvault, pastes the key once, and from then on it’s transparent for them too.