Laravel: No application encryption key has been specified

The error

Illuminate\Encryption\MissingAppKeyException

No application encryption key has been specified.

Sometimes the related one, which means the key exists but is not usable:

The only supported ciphers are AES-128-CBC and AES-256-CBC with the correct
key lengths.

What the key does

APP_KEY is the secret behind everything the framework encrypts or signs: session payloads, encrypted cookies, Crypt::encrypt() calls, encrypted model casts, signed URLs and password reset tokens.

That list is the important part of this page. The error looks like configuration and the consequences are data.

On a new install

Nothing is encrypted yet, so this is the trivial case:

cp .env.example .env
php artisan key:generate

On a system with data - stop first

php artisan key:generate is the first search result and it is the wrong first move here, because a new key does not fail to decrypt old data. It produces garbage or an exception, permanently, for every value encrypted under the previous key.

Work out what you would lose before changing anything:

grep -rn "Crypt::\|encrypted" app/Models app/Services

Sessions and cookies - no real loss. Everyone is logged out once.

Encrypted casts and Crypt:: values - permanent loss. Personal data, API credentials for third parties, anything stored with encrypted in a model's $casts. There is no recovery path. The old key is the only thing that could read them.

Signed URLs and reset tokens - outstanding links stop working. Recoverable by reissuing them, annoying rather than fatal.

If the second category is not empty, the task is finding the old key, not generating a new one. Look in your host's environment settings, your secrets manager, a colleague's local .env, the deployment configuration, an old backup of the environment file. The key does not have to be in the repository to still exist somewhere.

The usual causes

No .env at all. A fresh checkout, or a deployment that never created it.

The key is set but not being read. Cached configuration from before the key was added:

php artisan config:clear

This one deserves care in production - if config:cache runs during deploy and the environment variable is missing at that moment, the cached config freezes the absence, and later fixing the environment changes nothing until the cache is rebuilt.

The key is set in the wrong place. Containers and platform hosts often ignore a committed .env entirely and inject environment variables directly. A key sitting in a file nothing reads produces this error while looking correct.

The prefix was lost. base64: matters. Without it the same string is a different, wrongly-sized key.

Quoting. A key wrapped in quotes in a .env file can arrive with the quotes attached, depending on how the file is parsed.

If you have already generated a new key

Be honest about what happened rather than hoping. Find every encrypted column, attempt to read one, and confirm whether it decrypts. Where it does not, the only path forward is re-collecting the values - asking users to re-enter credentials, regenerating third-party API keys from those providers' own dashboards.

The one thing not to do is leave it. Encrypted columns that silently fail to decrypt turn into runtime errors at the least convenient moments, months later, in whatever code path happens to read them first.

Preventing the next one

Treat APP_KEY as a credential with the same handling as a database password: stored once, in your secrets manager, backed up where you back up credentials, and identical across every server that serves the same application. Add a deployment check that fails loudly when it is missing, rather than one that starts an application which will throw on its first request.

A deployment check that fails loudly belongs with the other things a deploy has to get right, and there are four of them. If nobody owns the servers and this is the third surprise this quarter, a maintenance arrangement is the cheaper answer.