Your encryption key when you export or import store data

When you download a copy of your store's data, or upload data to replace what's in your store, one detail matters more than any other: your encryption key. This page explains what it is, how it travels with your data, and why your store keeps working afterwards.

Why the encryption key matters

Your store has a single encryption key — a long, random value created automatically when your store is first set up, and unique to your store (Magento calls it the crypt key). Magento uses it to scramble certain sensitive settings before saving them to your database, and to unlock those same settings again whenever your store needs them. The most important of these is your payment gateway credentials; some third-party integration keys are protected the same way. The encrypted values live in your database, but the key that unlocks them lives in your store's configuration file (app/etc/env.php).

The consequence is simple but easy to get wrong:

A copy of your database is only fully usable if the matching encryption key travels with it. Move a database without its key and those encrypted settings become unreadable — your payment methods and any affected integrations would have to be re-entered.

What your exports contain

Your exports are built so your data stays usable, without ever exposing the credentials your store uses to run:

• Database export. Alongside the database itself, the download includes a small file, env-excerpt.json, containing your encryption key, your Magento version, and your database name and user. It deliberately contains no passwords and no connection details. The encryption key is included precisely so the encrypted settings in your data stay readable wherever you take it.
• Application code export. Your code download includes your store's configuration file (app/etc/env.php), but sanitized: it keeps your encryption key and database name/user, and strips every password and connection detail. As a safety check, the export refuses to complete if any password is still present — so a code export is always safe to hand to a developer or agency.

What an export never contains: the passwords and connection details your store uses to reach its database, cache, and file storage. Those are part of your hosting configuration, managed for you, and don't need to travel — leaving them out keeps your exports safe to store and share.

Keep your database export private. Because it carries your encryption key, treat the file like a password: store it securely and share it only with people you trust with your store's data.

What an import does

When you import data into your store, we reconcile the encryption key and protect the configuration your store needs to run:

• Importing a database. We read the encryption key from your export's env-excerpt.json and apply it to your store, so the encrypted settings in the imported database — payment credentials and the like — are immediately readable. Nothing else about how your store connects is changed.
• Importing application code. Your uploaded code includes that sanitized configuration file, which on its own would be missing the passwords and connection details your store needs. So on import we keep your store's existing configuration and ignore the connection settings in your upload. Your code is replaced; your store keeps working.

In short:

Your store's live connection settings (database, hosts, cache) are always preserved — an import never overwrites them with the ones from your upload.

A database import does, however, reset a few of your store's own settings to safe defaults — because the imported database carries the source store's values in place of yours. After a database import:

• your main admin account gets a new password (find it in your portal under your admin login details);
• your store's web addresses are re-pointed to this store; and
• email sending is reset to the default no-reply address (set up sending from your own domain again if you had that configured).

This happens on every database import — including re-importing a copy of your own store — so it's expected, not a fault. See migrating-in-from-another-host.md.

Practical guidance

• Moving a full store in? Import your code and database with Code + database together (the safer way) — the database carries and applies your encryption key — then import your media. Coming from another host (a plain database dump, not a copy from us)? Paste your encryption key into the database-import screen — find it in your old app/etc/env.php under crypt → key. migrating-in-from-another-host.md shows exactly how.
• Only importing code or media? Your encryption key is left unchanged, which is correct: neither touches your encrypted data.
• Importing a database from a different Magento version? Give your store a few minutes to reconcile its schema before relying on it.
• Remember that importing replaces the data already in your store. Make sure you have a recent backup before you import, so you can restore if the result isn't what you expected.