How to Rotate a Leaked Laravel APP_KEY Without Breaking Your App

You pushed a commit, opened an old branch, or read a support ticket, and there it is in plain text: your production APP_KEY. Now you have two bad options in front of you. Leave the key in place and hope nobody noticed, or change it and risk logging out every user and shredding your encrypted database columns.

Neither is acceptable, and neither is necessary. Since Laravel 11 there is a clean way to rotate the key that keeps users logged in and keeps your encrypted data readable, as long as you do it in the right order. This guide walks through what the key actually touches, how to measure your blast radius before you change anything, and the exact rotation procedure that cuts off an attacker without taking your app down.

Short version: put the current key into APP_PREVIOUS_KEYS, generate a new APP_KEY, deploy, re-encrypt any stored ciphertext, and then remove the old key. For a confirmed leak you also need to retire that previous key quickly, because it stays valid while it is in the list.

Why a leaked key is not just an encryption problem

It is tempting to think of the APP_KEY as protecting privacy: if it leaks, someone can read your encrypted cookies. That undersells it badly.

Laravel accepts any incoming cookie whose signature verifies against the APP_KEY. The session cookie, and every encrypted cookie, carries a message authentication code the framework checks before it decrypts and deserializes the contents. An attacker who holds your key can produce a cookie that passes that check, containing a serialized PHP object of their choosing. When Laravel unserializes it, that object can kick off a property-oriented gadget chain in a library somewhere in your vendor tree and end in code execution on your server. We covered the mechanics of that in detail in the APP_KEY exposure and RCE write-up.

So a leaked key is not a "rotate it when convenient" secret. It is a live path from your inputs to your shell. Treat the exposure as an incident, and treat the rotation as the fix.

Step one: measure the blast radius

Before you touch anything, find out what actually depends on the key. The answer decides whether this is a five minute job or a careful migration.

The key is used in four places, and they are not equally painful:

Notice what is not on the list. Sanctum personal access tokens are hashed with SHA-256, not encrypted with the key, so they are unaffected. Passport signs its tokens with a dedicated RSA key pair in storage, so it is independent of APP_KEY. Password hashes come from bcrypt or Argon2id and never touch the key. If your app has none of the four items above beyond ordinary sessions, rotation is low risk and the worst case is a wave of logouts.

The row that ruins weekends is the second one. Run a quick grep to find it:

grep -rn "Crypt::encrypt\|'encrypted'\|=> 'encrypted:" app/

Also check your model casts for encrypted, encrypted:array, encrypted:json, and encrypted:collection. Every column behind one of those was written with the old key. If you find any, you are doing a migration, not a swap, and the steps below matter.

Why the naive rotation hurts

The instinct is to run one command:

php artisan key:generate

On its own, key:generate overwrites APP_KEY in your .env and throws the old value away. Nothing remembers the previous key. The moment the new key is live:

• Every session cookie fails its signature check, so every user is logged out.
• Every value in an encrypted column was written with the old key, which no longer exists anywhere, so Crypt::decrypt throws DecryptException and the data is unreadable.

That second point is the one that turns a routine rotation into data loss. There is no undo once the old key is gone and the ciphertext is all you have left.

APP_PREVIOUS_KEYS: rotate without the outage

Laravel 11 added graceful key rotation, and it is the whole reason this can be painless. There is a previous_keys entry in config/app.php that reads a comma separated list from the environment:

// config/app.php
'previous_keys' => [
    ...array_filter(
        explode(',', env('APP_PREVIOUS_KEYS', ''))
    ),
],

The rule Laravel follows is simple. It always encrypts new data with the current APP_KEY. When it decrypts, it tries the current key first, then walks through each key in APP_PREVIOUS_KEYS until one works. That single behaviour is what lets old cookies and old ciphertext keep working after you introduce a new key, and it is what makes a zero-downtime rotation possible.

The safe rotation procedure

Here is the sequence that keeps users logged in and keeps encrypted data readable. Do it in this order.

1. Copy the current key into the previous keys list. Take the value currently in APP_KEY and set it as APP_PREVIOUS_KEYS. Do this by hand so nothing is lost, since key:generate will not do it for you.

# .env, before generating anything
# APP_KEY=base64:OLDKEYVALUE...
APP_PREVIOUS_KEYS=base64:OLDKEYVALUE...

2. Generate the new key. Now let Laravel mint a fresh APP_KEY:

php artisan key:generate

Your .env now has a new APP_KEY and the old one preserved in APP_PREVIOUS_KEYS.

3. Deploy and clear config cache. Push the change to every server and process that runs your app, including queue workers and scheduler, so they all share the same key material. If you cache config, rebuild it:

php artisan config:clear
php artisan config:cache

At this point new sessions and new encrypted values use the new key, while old cookies and old ciphertext still decrypt through the previous key. Users stay logged in. Nothing has broken.

4. Re-encrypt stored data. Any encrypted column is still sitting there in old-key ciphertext. Rewrite each row so it is re-encrypted with the current key. A one-off command is the safest way, because reading and re-saving an attribute runs it through the current key on the way back in:

// app/Console/Commands/ReEncryptSecrets.php
public function handle(): int
{
    Account::query()->chunkById(500, function ($accounts) {
        foreach ($accounts as $account) {
            // Reading decrypts with the previous key,
            // saving re-encrypts with the current key.
            $account->api_secret = $account->api_secret;
            $account->saveQuietly();
        }
    });

    $this->info('Re-encryption complete.');

    return self::SUCCESS;
}

Run it, verify a sample of rows decrypt cleanly, and only then move on. Do this for every model and column you found in the grep from earlier.

5. Retire the old key. Once every encrypted value has been rewritten and enough time has passed for old session cookies to expire, remove the old key from APP_PREVIOUS_KEYS and deploy again. The rotation is now complete and only the new key exists.

The catch that matters for a real leak

There is a security subtlety in step five that a lot of guides skip, and it is the most important part when the key genuinely leaked rather than being rotated on a schedule.

While the old key sits in APP_PREVIOUS_KEYS, it is still a valid key. Laravel will happily accept a cookie signed with it. That is exactly the behaviour you want for a smooth rotation, but it means an attacker who already has the leaked key can keep forging valid cookies for as long as it remains in the previous list. The graceful window that protects your users also protects the attacker.

So the calculus changes depending on why you are rotating:

• Planned rotation, no known compromise. Keep the old key in APP_PREVIOUS_KEYS as long as you need to migrate data comfortably. There is no adversary racing you.
• Confirmed or suspected leak. Migrate fast and drop the previous key as soon as the encrypted data is re-encrypted. If you have no encrypted columns to preserve, do not use APP_PREVIOUS_KEYS at all. Rotate straight to the new key and accept that every user is logged out. A wave of logins is a small price for immediately invalidating every cookie the attacker could forge.

In an incident, forcing everyone to re-authenticate is a feature, not a regression.

If you are still on Laravel 10 or older

APP_PREVIOUS_KEYS does not exist before Laravel 11, so there is no built-in fallback. Your options are to accept the logout and data loss, or to write a migration script that decrypts every encrypted value with the old key explicitly and re-encrypts it with the new one before you flip APP_KEY. You can construct an Illuminate\Encryption\Encrypter instance with a specific key to read the old ciphertext:

$old = new Illuminate\Encryption\Encrypter(
    base64_decode(substr($oldKey, 7)), // strip the "base64:" prefix
    config('app.cipher')
);

$plaintext = $old->decrypt($ciphertext);

Read with the old encrypter, write with the app default, then swap the key. It is more manual, and it is one more reason to get onto a supported Laravel release. The Laravel security checklist for 2026 covers keeping your framework current alongside the other controls that matter here.

Stop the next leak before it happens

Rotating the key fixes today's exposure. It does nothing about the next one, and the next one usually comes from the same handful of mistakes.

Keys leak because a .env file gets committed to a repository, because the file is reachable over HTTP at /.env on a misconfigured server, because a production error page renders the environment in a stack trace, or because the value ends up in a log line or an unencrypted backup. Each of those is preventable. Make sure .env is in your .gitignore, confirm APP_DEBUG is false in production, and verify the file cannot be fetched from the web. We go deeper on the exposure paths in why an exposed .env file is so dangerous and on the cookie side in Laravel session cookie security.

The hard part is knowing whether any of those doors are currently open on your live site, because from the outside is exactly where an attacker looks. StackShield scans your application externally, the same way an attacker would, and flags an exposed .env, a leaking debug page, and the misconfigurations that turn a stray secret into a breach. Run a free scan and find out what your production environment is giving away before someone else does.