Anonymization

Basecut applies anonymization during extraction, before data is written to a snapshot. Restores to dev, CI, or staging receive already-masked rows, so masking cannot be skipped as a separate step. For the full anonymize block and all YAML fields, see YAML Reference. For organization-wide enforcement, see Snapshot rules.

Quick start

anonymize: auto

auto turns on built-in PII detection and still lets you add explicit rules for overrides.

Modes

Mode	Behavior
`auto`	Built-in PII detection plus any explicit `rules`.
`manual`	Only explicit `rules` — no auto-detection.
`off`	No anonymization.

Which mode should I use?

Use auto if you want the safest default for most development, CI, and staging workflows. It catches common PII automatically and still lets you add overrides.
Use manual if you need full control over exactly which fields are masked and how. This is common when your schema has unusual field names or domain specific rules.
Use off only when you are certain the source data contains no sensitive information or you are working with already-anonymized input.

Shorthand:

anonymize: auto
# anonymize: off

Object form:

anonymize:
  mode: auto
  excluded_domains:
    - yourcompany.com
  rules:
    users:
      email: fake_email
      phone: fake_phone
    '*.password_hash': redact

Rules

Use table-grouped keys for public tables (unqualified names resolve to public.<table>) or wildcard keys for patterns such as *.email.

anonymize:
  mode: manual
  rules:
    users:
      full_name: fake_name
      date_of_birth:
        strategy: date_shift
        params:
          days: 90
    '*.email': fake_email

Complex strategies use strategy + optional params (for example partial_mask with visible, numeric_noise with percent).

Internal and test emails

Top-level excluded_domains skips anonymization for matching email domains (case-insensitive). Per-rule params.excluded_domains overrides that list for a single field. Details and examples are in YAML Reference — anonymize.

Organization policies

On Team and Enterprise plans, Snapshot rules in the app can require specific strategies (for example *.email: fake_email) and excluded tables across every snapshot. See Snapshot rules.

Strategies

Strategy	Description
`none`	No transformation
`redact`	Replace with `[REDACTED]`
`null`	Replace with `null`
`fixed`	Replace with `params.value`
`hash`	Deterministic hash
`fake_name`	Realistic full name
`fake_first_name`	First name
`fake_last_name`	Last name
`fake_email`	Realistic email
`email_preserve_domain`	Fake local part, original domain
`fake_phone`	Phone number
`fake_date_of_birth`	Date of birth
`fake_username`	Username / handle
`fake_credit_card`	Luhn-valid card number
`fake_ssn`	SSN-like value
`fake_passport`	Passport-like value
`fake_iban`	IBAN-like value
`fake_routing_number`	Routing number
`fake_bank_account`	Bank account–like value
`fake_company`	Company name
`fake_job_title`	Job title
`fake_address`	Street address
`fake_city`	City
`fake_state`	State or province
`fake_zip`	Postal code
`fake_country`	Country
`fake_ip`	IP address
`fake_mac`	MAC address
`fake_uuid`	UUID
`fake_url`	URL
`fake_paragraph`	Paragraph of text
`partial_mask`	Mask value; `params.visible` = trailing chars kept
`date_shift`	Shift date; `params.days`
`numeric_noise`	±`params.percent` variance

Getting Started

Core Concepts

Configuration

Workflows

Integrations

CLI Reference

Deployment

Reference

Quick start

Modes

Which mode should I use?

Rules

Internal and test emails

Organization policies

Strategies

See also

​Quick start

​Modes

​Which mode should I use?

​Rules

​Internal and test emails

​Organization policies

​Strategies

​See also

Quick start

Modes

Which mode should I use?

Rules

Internal and test emails

Organization policies

Strategies

See also