cloning:dump

Inspect a live database and generate a .cloning.yaml configuration file that describes how to anonymize each column when cloning the database to a target environment.

Synopsis

clonio cloning:dump [options]

Options

Description

cloning:dump connects to a database, reads its schema (tables and columns), and runs the PII auto-detection engine against every column name. It then writes a cloning.yaml file that:

• Lists every table in the database
• For each column that matched a PII pattern, assigns the recommended anonymization strategy (e.g. fake, hash, mask)
• For all non-PII columns, defaults to keep (no transformation)

The generated file is meant to be reviewed, adjusted, and committed to your repository. Once you're satisfied with the configuration, use cloning:run to apply it.

Prerequisites

1. Run clonio init in your working directory to create a .env file with APP_KEY
2. Add a connection with clonio connection:add
3. (Optional) Customise PII detection with clonio matchers:init

Usage

Basic usage

clonio cloning:dump --connection production-db

This will:

1. Connect to the production-db database
2. Inspect its schema
3. Run PII detection on all column names
4. Write production-db.cloning.yaml in the current directory

Interactive connection selection

If you omit --connection, Clonio will prompt you to choose from your saved connections:

clonio cloning:dump

 Select a connection to inspect:
  [0] production-db
  [1] staging-db
 > 0

  Inspecting "production-db" (pgsql @ db.prod.io:5432) ...

  Schema fetched: 24 tables, 187 columns

  Transfer options:
    Enforce column types on target? (no)
    Drop unknown tables on target? (no)
    Drop extra columns on target? (no)
    Disable foreign key checks? (yes)

  PII auto-detection:
    ✓  12 columns matched across 5 tables
    ○  175 columns set to keep

  Written: ./production-db.cloning.yaml

  Review the file, adjust strategies as needed, then run:
    clonio cloning:run production-db.cloning.yaml --target <name>

Custom output path

clonio cloning:dump --connection production-db --output config/cloning.yaml

Overwrite an existing file

clonio cloning:dump --connection production-db --force

Only include PII columns

Use --only-pii to generate a minimal config that only lists tables and columns where PII was detected. Tables with no PII columns are omitted entirely.

clonio cloning:dump --connection production-db --only-pii

Framework tables

Many applications ship tables whose rows are transient, secret or personal: cache entries, sessions, queued jobs, password reset and API tokens, debug logs. The application needs these tables, but copying their rows to a dev or test environment is risky and rarely useful.

cloning:dump recognizes known framework tables and suggests the schema row strategy for them: the table is created on the target, no rows are copied.

  Known framework tables (cache, sessions, queues, tokens, logs):
    cache (Laravel cache)
    sessions (Sessions)
    personal_access_tokens (API tokens)

  Copy only the schema of these tables, without rows? (yes/no) [yes]:

In --ci mode the suggestion is applied without asking. Use --no-framework-tables to keep these tables on full.

Names are matched case-insensitively. Schema-only tables stay in the YAML even with --only-pii.

Setting transfer options at dump time

After inspecting the schema, Clonio prompts for five transfer options that control how cloning:run synchronizes the target schema and transfers data. In interactive mode you answer yes/no at the prompt; defaults match the recommended safe settings:

In --ci mode the prompts are skipped and only the flags apply:

clonio cloning:dump --connection production-db --ci \
  --enforce-column-types \
  --drop-unknown-tables

The chosen values are written directly into the options: block of the generated YAML and serve as the baseline for every cloning:run against that file. Individual run-time overrides are available via cloning:run flags (see "Schema Synchronization" in cloning:run).

CI mode

In CI pipelines, use --ci to suppress interactive prompts and non-error output. --connection is required in this mode.

clonio cloning:dump --connection production-db --ci

Custom Faker locale

The generated config uses en_US as the default Faker locale for generating fake data. Override with --locale:

clonio cloning:dump --connection production-db --locale de_DE

Output file format

The generated cloning.yaml follows this structure:

# yaml-language-server: $schema=https://clonio.dev/schema/cloning-v1.json
version: "1"
connection: production-db

options:
  chunk_size: 1000
  enforce_column_types: false
  drop_unknown_tables: false
  drop_extra_columns: false
  recreate_tables: false
  disable_foreign_key_checks: true
  faker_locale: en_US

tables:
  users:
    rows:
      strategy: full
    columns:
      # PII: Email Address
      email:
        strategy: fake
        faker_method: safeEmail
        faker_arguments: []
      # PII: Password / Secret
      password:
        strategy: hash
        algorithm: sha256
        salt: ""

  orders:
    rows:
      strategy: full
    # no PII detected — no columns listed; all kept as-is

Column strategies

Row strategies

PII detection

Clonio ships with a built-in set of PII matchers covering common column names for:

• Personal identity (name, first_name, last_name, date_of_birth, etc.)
• Contact information (email, phone, address, city, etc.)
• Location (latitude, longitude, postcode, etc.)
• Financial (iban, credit_card_number, bank_account, etc.)
• Authentication (password, secret_key, api_key, etc.)
• Network (ip_address, mac_address, etc.)

To customise which columns are detected and what transformations are applied, use:

clonio matchers:init   # export the baseline matchers to clonio.pii-matchers.yaml
clonio matchers:list   # view all active matchers
clonio matchers:check <column>  # test a column name against matchers

Workflow

1.  cloning:dump --connection production-db
    → generates production-db.cloning.yaml

2.  Review the file:
    - Adjust strategies (e.g. change hash to fake for passwords)
    - Add missing PII columns
    - Tune row strategies (full vs first/last with limit)
    - Set salt values for hash strategies

3.  Commit to your repository

4.  cloning:run production-db.cloning.yaml --target local-dev
    → applies the config, cloning production → local-dev

Exit codes

Related commands

• cloning:run — apply a cloning config to transfer and anonymize a database
• matchers:init — export baseline PII matchers to a customisable file
• matchers:list — list all active matchers and their patterns
• matchers:check <column> — test a column name against the active matchers
• connection:add — add a database connection