sanitize

Run the sanitization pipeline on a database snapshot.

Usage

clonit sanitize <target> [snapshot_index] [flags]

Arguments

Argument	Description	Required
`target`	Name of the target	Yes
`snapshot_index`	Index of the snapshot to sanitize	No (defaults to latest)

Flags

Flag	Type	Default	Description
`--validate`	bool	`false`	After sanitizing, verify the sanitized data no longer contains sensitive values and fail the command if it does (see Validation)
`--no-push`	bool	`false`	Skip the automatic push of the sanitized snapshot to storage (see Auto-push)

Description

Executes a three-step sanitization pipeline on the specified snapshot:

Restore: The source snapshot is restored into the sanitize destination database (sanitize_dst_url).
Execute: The sanitization SQL query file (sanitize_query_file) is executed against the sanitize destination database to scrub, mask, or transform sensitive data.
Dump: The sanitized database is dumped to create a new sanitized snapshot.

The target must have both sanitize_dst_url and sanitize_query_file configured. Use targets add or targets update to set these fields.

Validation report

With --validate, clonit runs a verification pass over the sanitized data once the sanitized snapshot has been produced. It loads the target’s latest completed analyze run and, for every column that analysis flagged as sensitive, samples up to 1000 values and runs pure-pattern detectors (email, phone, SSN, credit card, IPv4 — chosen by the column’s category). A match means a value that should have been scrubbed is still present.

Opt-in. Without --validate, nothing runs and the command behaves exactly as before.
Privacy posture — counts only. The report records only per-column match counts and the detector name. A matched value is never printed, logged, or stored. Nothing that could itself be sensitive leaves the detector.
Exit-code contract (CI gate). The sanitized snapshot is always produced and recorded; validation only affects the exit code:
- passed — no sensitive values found → success, exit 0.
- failed — matches found → a violations table (table / column / detector / matches) is printed and the command exits non-zero, so a CI pipeline gating on clonit sanitize --validate fails the build. The snapshot still exists.
- skipped — the target has no completed analysis (run clonit analyze first) → a warning is printed, exit 0.
- error — validation could not connect to the sanitized database → a warning is printed, exit 0 (the sanitize itself succeeded).

The report is persisted on the sanitized snapshot and shown in the web UI’s snapshot detail view.

To re-check an already-produced snapshot against a newer analysis without re-sanitizing it, use snapshots validate, which loads the stored snapshot into a throwaway container and runs the identical validation pass.

Auto-push

After a successful sanitize (and after the optional validation pass), the sanitized snapshot is automatically pushed to the target’s sanitized storage profile (--sanitized-storage-profile on targets add/update) when defaults.auto_push is true (the default) and --no-push is not set. The rule is strictly per-type: a sanitized snapshot never falls back to the target’s original storage profile – without a sanitized profile it silently stays local.

Two more guarantees:

Validation gate. If --validate ran and the report failed, the snapshot is not pushed – data that failed its PII gate stays local (a warning is printed; push manually once fixed). A report with status error (validation could not run) keeps the snapshot local too: only passed/skipped reports (or no report at all) push.
Non-fatal. A push failure prints a warning but never fails the sanitize run; retry with clonit push <target>.

See build – Auto-push for the shared rules.

Examples

Sanitize the latest snapshot:

clonit sanitize mydb

Sanitize a specific snapshot by index:

clonit sanitize mydb 0

Sanitize and fail the command if any flagged column still contains sensitive data (useful as a CI gate):

clonit sanitize mydb --validate