Clonio CLI: Clone Production Databases With Anonymized Data

Clonio CLI copies a production database into development, CI, and test environments and rewrites the sensitive columns on the way through — faking names and emails, masking tokens, and remapping primary keys so the data is usable but no longer identifies real people.

• Per-column anonymization with fake, mask, hash, static, null, and template strategies
• Key remapping that reassigns primary keys and updates the foreign keys pointing at them
• PII detection matchers that flag sensitive columns missing a transformation
• Signed audit artifacts delivered to local storage, S3, Slack, Teams, or email
• Multiple distributions — standalone binary, PHAR, Docker image, or Composer dev dependency

The configuration lives in a version-controlled .cloning.yaml file that references connection names rather than credentials, so it's safe to commit alongside your application code.

#Column Transformation Strategies

Each column you want to change gets a strategy in the YAML file; columns you don't list are copied as-is, so you only describe the data that needs to change. The available strategies are:

• fake — generate synthetic values with FakerPHP
• mask — keep a few leading characters and mask the rest
• hash — one-way hash a value (pseudonymization, not true anonymization)
• static — replace with a fixed string
• null — set the column to NULL
• template — mix literal text with faker placeholders
• remapping — assign new primary keys and update the foreign keys that reference them

A trimmed users table might look like this:

version: "1"
connection: production
options:
  faker_locale: de_DE
 
tables:
  users:
    rows:
      strategy: last
      limit: 5000
      sort_by: created_at
    columns:
      email:
        strategy: fake
        faker_method: safeEmail
      first_name:
        strategy: fake
        faker_method: firstName
      phone:
        strategy: mask
      internal_notes:
        strategy: "null"

Clonio is explicit that hash output still counts as personal data under GDPR, and points you to fake or null when re-identification needs to be impossible.

#Key Remapping Across Related Tables

Copying rows into a target database can collide with existing primary keys. The remapping strategy replaces a table's primary keys with new values and consistently updates the foreign keys in dependent tables, so referential integrity survives the transfer rather than breaking on import.

#PII Detection

Rather than relying on you to spot every sensitive column by hand, Clonio ships matchers that flag columns likely to hold PII. matchers:init sets up the baseline patterns, matchers:list shows the effective rules, and matchers:check validates your tables against them — a way to catch a new email or tax_id column that someone added without a transformation strategy.

#Audit Trail

Every cloning run can emit a signed audit artifact plus structured logs, written locally, to S3-compatible storage, or delivered to Slack, Microsoft Teams, or email. The cloning:verify-audit command checks the integrity of those logs after the fact, which matters when you need to demonstrate that production data was anonymized before it reached a less-trusted environment.

#Installation

Clonio runs as a standalone binary (Linux x86_64/aarch64 and macOS Apple Silicon, no PHP required), a PHAR archive for PHP 8.5+, a Docker image (ghcr.io/clonio-dev/clonio:latest), or a Composer dev dependency:

composer require --dev clonio-dev/clonio-cli

The basic workflow is to initialize the project, register a production connection, generate a cloning config from its schema, and run it against a target:

clonio init
clonio connection:add production --production
clonio cloning:dump --connection production
clonio cloning:run production.cloning.yaml --target ci

You can find the source, documentation, and release downloads on GitHub.