Here's a fun one. You build a package that backs up an app's config — the .env plus the settings stored encrypted in the database — into a single password-protected ZIP. The whole selling point is portability: take a backup on server A, restore it on server B, even when the two servers have different APP_KEYs. Then you write a test that actually changes the key during a restore, and it fails. The DB settings come back garbled.
Turns out the bug wasn't in the encryption at all. It was in a cache I forgot was there. Today I shipped 1.1.0 of laravel-config-backup and this portability fix was the headline. Let me walk through it, because the lesson generalizes way beyond this package.
Why APP_KEY portability is even a thing
Laravel encrypts things with APP_KEY. Encrypted Eloquent casts, signed cookies, sessions — all of it keys off that value. So if you naively mysqldump a table with encrypted columns and load it onto another server, every encrypted column is now ciphertext that the new key can't decrypt. Dead data.
The trick this package uses is to store the archive contents decrypted. When I export the database, rows go out through their casts, so an encrypted column becomes a plain value inside the ZIP (the ZIP itself is AES-256 password-encrypted, so it's not sitting around in plaintext). On import, each row is written back through the model, which means the cast re-encrypts it with whatever APP_KEY is active on the destination.
