The Encryption Key: Why It's Critical and How to Avoid Losing It

Last updated: September 2026

This is the single easiest thing to get wrong when setting up or moving a self-hosted shop, and getting it wrong silently breaks Stripe and email rather than throwing an obvious error. Read this before you touch Stripe or SMTP credentials.

\r\n

What It Actually Protects

\r\n

Your Stripe keys, SMTP password and any email-marketing credentials are never stored in plain text. They're encrypted in the database using a key you generate yourself — your ENCRYPTION_KEY. Without the exact key that encrypted them, those credentials cannot be read back, by you or by the application.

\r\n

Generating It

\r\n

With your virtual environment activated, run:

\r\n

python manage.py generate_encryption_key

\r\n

Add the value it prints to your .env file:

\r\n

ENCRYPTION_KEY=your-generated-key-here

\r\n

Do this once, early — before you enter any Stripe or SMTP credentials into the admin or your .env. Every credential you save afterwards is encrypted with whichever key is active at that moment.

\r\n

The Failure Mode That Actually Happens

\r\n

If you re-upload your project to a new server, restore a database backup, or start from a fresh .env.example without carrying over the same ENCRYPTION_KEY value, the application generates or expects a different key than the one your existing credentials were encrypted with. The result isn't an error message — it's Stripe and email quietly failing, because the stored credentials decrypt into garbage instead of your real keys.

\r\n

This is exactly what happens if you treat ENCRYPTION_KEY as just another environment variable to regenerate on a fresh install: any shop that already has real Stripe/SMTP credentials saved will need every one of those credentials re-entered from scratch once the key changes, because the old encrypted values are now unreadable.

\r\n

How to Avoid It

\r\n
    \r\n
  • Back up your ENCRYPTION_KEY alongside your database, not just the database itself. A database backup without the matching key is only half a backup.
  • \r\n
  • When moving to a new server or re-uploading a build, copy your existing .env file across (or at minimum, the exact ENCRYPTION_KEY value) — never generate a new one on a site that already has encrypted credentials saved.
  • \r\n
  • Only run generate_encryption_key once, on a brand-new install with no Stripe/SMTP credentials entered yet. If you've already saved credentials and need to rotate the key, you'll need to re-enter every encrypted field afterwards under the new key — there's no way to re-encrypt existing values automatically.
  • \r\n
\r\n

If Stripe or email suddenly stops working after a redeploy or server move with no obvious cause, check this first: is ENCRYPTION_KEY in the current .env the same value it was before the move?

\r\n
\r\n

← Back to the Managed Hosting vs Self-Hosting Guide