The Laravel application key protects encrypted application data. Moving a working site normally requires preserving its existing key, rather than generating a replacement merely because the server changed.
IN THIS ARTICLE
What you need before you begin
Identify where production secrets are stored and confirm you have an authorised backup. Decide whether this is an ordinary migration or a deliberate key rotation after a security incident.
01 Keep a Laravel application key safe during migration
Read the production secret through your approved secret-management process. Transfer it through a protected channel to the new runtime without placing it in Git, a support ticket or a publicly downloadable archive.
Configure the new application with the existing key and compatible cipher settings. Preserve the database and any encrypted values that belong to the same application.
Test the destination with a separate preview address or controlled host mapping. Check an actual encrypted application value as well as login behavior.
If rotation is necessary, review the key-rotation features of your Laravel version and the application code that encrypts data. Where supported, configure previous keys for a planned transition. Previous-key fallback allows decryption; it does not automatically rewrite stored ciphertext. Re-encrypt or deliberately retire any retained values that depend on the old key before removing it from the running application, and test this in staging. Preserve any keys still needed to restore historical backups in protected recovery storage. For a compromised key, coordinate session invalidation and data re-encryption with the incident response plan instead of leaving it accepted indefinitely.
After the cutover, rebuild configuration caches and restart long-running processes so they use the intended secret. Revoke temporary transfer access.
Confirm the expected result
Confirm users can complete the relevant authenticated workflow and that encrypted records remain readable. A successful homepage is insufficient evidence that the correct key is loaded.
Troubleshoot unexpected results
An invalid message authentication code or unreadable encrypted value can indicate a wrong key, a stale configuration cache or data from another environment. Restore the verified configuration before modifying stored records.
A common question
Should I run key:generate on an existing production site?
Not as a routine migration step. Generate a new key for a new application, or follow a tested rotation plan for an existing application. Replacing the key without preparation can invalidate protected data or sessions.