Why is EnvironmentEncryptCommand not using LARAVEL_ENV_ENCRYPTION_KEY

[felix-exon]

The EnvironmentDecryptCommand is using LARAVEL_ENV_ENCRYPTION_KEY but the EnvironmentEncryptCommand is not?
I don't see a reason why?

So if I encrypt without a key, it seems to use a random string, while I would expect LARAVEL_ENV_ENCRYPTION_KEY to be used ?

if (! $keyPassed) {
    $key = Encrypter::generateKey($cipher);
}

[macropay-solutions]

Maybe because it asks for a key?
https://github.com/laravel/framework/blame/d8c8dc9cb39217cad9420ee61effc3705b879ad0/src/Illuminate/Foundation/Console/EnvironmentEncryptCommand.php#L69-L82C10

Update see below the logical reason.

[macropay-solutions]

decript is not in dev and encript is in dev

Brave search:

The env:encrypt and env:decrypt commands in Laravel are not restricted to development only. Both can be used across environments, but their usage differs based on security practices.

• env:encrypt is typically run in development or locally to encrypt .env files (e.g., .env.production) into .env.production.encrypted, which can be safely committed to version control.

• env:decrypt is used during deployment or in production environments to decrypt the .env.encrypted file using the LARAVEL_ENV_ENCRYPTION_KEY. This key must be securely stored (e.g., in Vapor, Forge, or server environment variables), not in source control.
  Thus, while env:encrypt is usually run in development, env:decrypt is intended for use in production or deployment pipelines—not for local development. The misconception that decryption is "only for dev" may arise from local testing, but its primary purpose is secure decryption in production.

[felix-exon]

i disagree. for both commands the key is optional - so it would only make sense to use the same default when nothing is provided.
there is absolutely no logical use case (at least for me) for a one-off encryption with a random key - just like ransomeware ?

[felix-exon]

Analysis of the Encryption Key Inconsistency

Posted via Claude Code

---

I wanted to provide a more detailed analysis of this API inconsistency, as I believe the original point raised deserves stronger consideration.

The Core Problem

Looking at the two commands:

• EnvironmentDecryptCommand checks LARAVEL_ENV_ENCRYPTION_KEY as a fallback when no --key is provided
• EnvironmentEncryptCommand generates a random key instead of checking the same environment variable

This creates an asymmetric API where two closely related commands behave differently for the same optional parameter pattern.

Why This Matters

1. Principle of Least Surprise

When both commands accept --key as optional and one falls back to an environment variable, developers reasonably expect the other to do the same. This inconsistency creates cognitive overhead and potential confusion.

2. Real-World Use Cases

Consider a developer who:

• Has LARAVEL_ENV_ENCRYPTION_KEY set locally (mirroring their production/deployment setup)
• Needs to re-encrypt an environment file after making changes
• Runs php artisan env:encrypt --env=production

They would expect this to use their existing key. Instead, they get a new random key, which means they now need to update their deployment configuration unnecessarily.

3. The "Random Key" Default Has Sharp Edges

If someone runs the encrypt command without carefully capturing the output, they have created an encrypted file they can never decrypt. While the command does display the key, this UX pattern is more error-prone than checking for an existing key first.

Proposed Solution

A simple change to EnvironmentEncryptCommand would resolve this:

$key = $this->option("key")
    ?? env("LARAVEL_ENV_ENCRYPTION_KEY")
    ?? Encrypter::generateKey($this->parseEncryptionCipher());

This approach:

• ✅ Maintains backward compatibility (still generates a key if nothing is configured)
• ✅ Creates consistency with EnvironmentDecryptCommand
• ✅ Respects existing key configuration without requiring explicit --key flag
• ✅ Reduces risk of accidental key mismatch

Addressing the Counter-Argument

The argument that "encrypt runs locally, decrypt runs in production" describes a typical workflow but not the only valid workflow. The beauty of Laravel's optional parameters is flexibility—and that flexibility should be consistent across related commands.

If the commands were designed to be used in fundamentally different contexts, the decrypt command wouldn't need to accept a --key option at all (it could only read from the environment). But it does accept --key, which signals that both commands are meant to be flexible.

---

I believe this is worth a PR. The code change is minimal, the reasoning is sound, and it would improve developer experience without any breaking changes.

[macropay-solutions]

The key being a secret makes it logic for it to not be in the env file that is being encrypted by using it. In prod you store that key in aws secrets for example and on deploy you use that key to decrypt your prod env.
You storing that secret in your local env as plain text is not secure.

[macropay-solutions]

Also if you don't provide one, one will be auto-generated and exposed in console for you to use on deploy.

        $this->components->twoColumnDetail('Key', $keyPassed ? $key : 'base64:' . base64_encode($key));