Brume · GDPR-compliant PostgreSQL pseudonymization with FK preservation | Brume Skip to content<br>Quickstart
install · debian/ubuntu
# 1. Configure the repo (one time only)
$curl -1sLf \
'https://dl.cloudsmith.io/public/brume/brume/setup.deb.sh' \
| sudo -E bash
# 2. Install
$sudo apt-get install brume
# Updates afterwards
$sudo apt-get update && \
sudo apt-get upgrade brume
# 1. Configure the repo (one time only)
$curl -1sLf \
'https://dl.cloudsmith.io/public/brume/brume/setup.rpm.sh' \
| sudo -E bash
# 2. Install
$sudo dnf install brume
# 1. Configure the repo (one time only)
$brew tap brumeorg/brume
$brew trust --formula brumeorg/brume/brume
# 2. Install
$brew install brume
# Updates afterwards
$brew upgrade brume
brume plan<br>Deterministic PostgreSQL pseudonymization with foreign key preservation. For debugging, testing, demos — anywhere but production.
How it works
Start using Brume
Secure your data<br>Column-level pseudonymization with deterministic, keyed transformations.<br>Apply column-level pseudonymization with the strategy that fits each field. FAKE for realistic synthetic values, MASK for partial reveals, HASH for one-way hashing, NULLIFY<br>to drop sensitive data, or FPE_ID / FPE_UUID for format-preserving encryption of identifiers. Every transformation is deterministic and keyed by your hmac-secret and fpe-key:<br>same input + same secret = same output, every time. Two runs produce identical results — your tests stay stable, your debug sessions stay coherent across rebuilds.
Keep your constraint<br>Foreign keys stay valid end-to-end. No disabled triggers, no broken joins.<br>Foreign keys stay valid on the target database. No disabled triggers, no suspended integrity checks, no patching broken joins after the fact. Format-preserving encryption<br>rewrites primary keys and the FKs that point to them consistently, so referential integrity holds end-to-end. And when your business logic spans tables that aren’t formally<br>joined (e.g. an email shared between users and audit_logs), linked_columns guarantees the same real value produces the same fake value across all of them.
Take only what you need<br>Row-level filters with automatic FK traversal — a self-contained subset of your data.<br>Define row-level filters on any table (created_at >= ‘2025-01-01’, tenant_id = 42…) and let Brume traverse foreign keys automatically up to fk_depth levels. Both parents and<br>children. You get a self-contained, FK-coherent subset of your production data, scoped to exactly what your debug session or test environment needs. Nothing more, nothing less.
Fully configurable<br>Declarative brume.yml — semantic types, JSONB paths, version-controllable.<br>A single declarative brume.yml file describes, per table and per column, the strategy to apply. Semantic types (EMAIL, PHONE, IBAN, ADDRESS…) make generated data contextually<br>realistic, JSONB paths let you target nested fields individually, and the whole file is version-controllable, so you can review and sign off on the exact<br>transformation rules before any pseudonymization run touches a database.
…and much more.<br>Discover Brume features