New in Shopware CLI: Anonymize extension data in database dumps

When preparing a local or staging Shopware environment, you want production-like data while reducing the risk of exposing customer information or live credentials. Until now, Shopware CLI’s project dump --anonymize applied built-in rules to selected Shopware data, but didn’t read rules from extensions. An extension might write personal data to a core table, store sensitive data in its own tables, or keep credentials in system_config. Without extension rules, that data could remain in the dump. Project developers had to find and scrub it themselves.

We’re excited to announce that the Shopware CLI now extends project dump --anonymize capabilities to extensions – enabling extension authors to declare anonymization rules in an anonymize section of .config/shopware-extension.yml. The rules can cover columns in an extension’s own tables, data it adds to Shopware tables, and its system_config entries. When you run project dump --anonymize, the CLI loads rules from extensions in the project checkout, so rules from production extensions missing from that checkout won’t be applied.

For additional support, the CLI includes an agent Skill that reads an extension’s code and drafts the anonymize section for you. Both the feature and the Skill shipped in v0.19.2.

Why we did this

Until now, project dump --anonymize applied built-in rewrites to selected fields in seven core tables: customer, customer_address, log_entry, newsletter_recipient, order_address, order_customer, and product_review. It did not anonymize system_config, Shopware’s shared database table for settings. A payment extension’s live API keys in system_config or a newsletter extension’s own subscriber table could still go into the dump untouched. One Shopware agency in our ecosystem created a community registry of plugin data to overcome these hurdles.

If an extension has no anonymize section, it contributes no extension-specific rules. Any applicable built-in or project rules still apply. Data with no applicable rule remains unchanged in the dump. This increases the risk of data leaks.

Writing the rules in .config/shopware-extension.yml takes just a few lines, and projects whose checkout includes the extension get a cleaner dump.

How the config works

An anonymize section has two keys. tables defines column rewrites for tables containing extension data, including extension-owned tables and core tables the extension adds data to, such as customer.custom_fields. system_config defines rules for configuration entries.

anonymize:
  tables:
    swag_example_token:
      access_token: "''"
      email: faker.Internet.Email()
  system_config:
    - SwagExample.config.clientSecret # omit key
    - key: SwagExample.config.merchantEmail
      value: faker.Internet.Email() # set faker value
    - key: SwagExample.config.environment
      value: sandbox # set static value

tables uses the same column expressions as the project’s dump.rewrite map. "''" stores an empty string, "NULL" stores NULL, and a value starting with faker. is generated per row. system_config rules match system_config.configuration_key. A plain key omits that row from the dump; an entry with value replaces its stored value, for example with a Faker value or a static value such as sandbox.

When the CLI merges extension rules into a dump, these details apply:

• Project and built-in rules take precedence for columns they already rewrite. A rule under dump.rewrite in .shopware-project.yml, or a built-in rule, is left unchanged.

• Unreadable extension configs stop the dump. A Composer-locked extension found under vendor that cannot be loaded also causes an error. A package with no installed vendor directory is skipped.

• Conflicting extension rules have a defined outcome. For conflicting rewrites or different rules for the same system_config key, the first extension in name order wins and the CLI logs a warning.

• Compatible JSON rules are combined. When extensions remove different keys from the same column with JSON_REMOVE, the CLI merges their paths into one expression. Other custom fields are preserved.

For example, these rules from two extensions:

# First extension: anonymize.tables
customer:
  custom_fields: "JSON_REMOVE(custom_fields, '$.first_secret')"
# Second extension: anonymize.tables
customer:
  custom_fields: "JSON_REMOVE(custom_fields, '$.second_secret')"

produce:

JSON_REMOVE(custom_fields, '$.first_secret', '$.second_secret')

Let an AI agent write the first draft

Going through every entity and config field by hand is tedious, so let the agent Skill draft the section for you. Point your coding agent at the extension so it can inspect entity definitions, migrations, config.xml, and relevant code, then fill in the anonymize section of shopware-extension.yml. It can suggest rules for JSON, free-text, and unique columns, switch integrations to sandbox or test mode where possible, and run the CLI’s extension validation on the config. Treat its output as a starting point: review the rules and make sure they match the extension’s schema before committing them.

The more extensions declare their data, the less time spent on searching a dump for live API keys before loading it into staging or sharing it with a colleague.

If you maintain a Shopware extension, add an anonymize section in your next release, or let the Skill draft one for review. If you run Shopware projects, update to Shopware CLI 0.19.2; your next anonymized dump will pick up the rules declared by extensions the CLI finds in the project checkout. Anonymization reduces exposure but doesn’t guarantee compliance, so keep checking what leaves production.

We hope you try it out!