Weave Code
Laravel Masked Db Dump Laravel Package
beyondcode/laravel-masked-db-dump
Create safe, shareable database dumps from your Laravel app. Mask sensitive columns like emails, names, and tokens with customizable replacements, so you can hand off realistic data to teammates or use it in local development without leaking production secrets.
Dump masked information from your database
Frequently asked questions about Laravel Masked Db Dump
- How do I install beyondcode/laravel-masked-db-dump in a Laravel application?
- Install it as a dev dependency with composer require --dev beyondcode/laravel-masked-db-dump, publish the config with php artisan vendor:publish, then run php artisan db:dump. It registers a single Artisan command and adds no middleware, migrations, or runtime footprint, so it never touches production request paths. If your pipeline builds one artifact for all environments, confirm it actually runs composer install --no-dev or excludes the package explicitly.
- How do I configure which columns get masked in config/masked-db-dump.php?
- The published config maps tables to columns to replacement strings or PHP callables, so masking rules live in version control and can ship through PR review next to schema changes. Keep the map complete and current, because the package has no strict mode or allowlist enforcement and anything unmapped passes through verbatim.
- Does laravel-masked-db-dump support my Laravel and PHP version?
- It is a normal Composer package, so its composer.json carries the exact Laravel and PHP constraints. Check those against your app before adopting, especially on older LTS releases, and pin a version you have tested in your own pipeline.
- How does the db:dump command actually create the dump?
- It shells out to mysqldump or pg_dump, applies the column replacements declared in config, and writes an importable SQL file you can hand to teammates or load locally. There is no plugin layer or event system, so anything exotic means wrapping the command or post-processing the dump.
- Can I use Closures as mask replacements, and does that work with config:cache?
- The 5.0.0 docs favor PHP callables, but Closures stored in a config file cannot be serialized by Laravel's config:cache. Where config:cache runs, this is at best an error and at worst a degraded path that emits unmasked output, so add an explicit runbook step plus a pipeline assertion that the dump is still masked.
- Does laravel-masked-db-dump mask tables and columns that are not in the config?
- No. Masking is fail-open: unmapped tables and columns pass through verbatim, and there is no strict mode or assertion that every PII-shaped column is mapped. Add a compensating control such as a post-dump scan for a canary set of known real values wired into your runbook and CI, and keep the config updated as the schema evolves.
- How do I keep referential integrity when masking the same field across multiple tables?
- Use one documented deterministic callable per logical field and reuse it everywhere, so the same entity receives the same masked value in every table. Never mask primary or foreign keys; if the same entity is masked differently in two tables, joins break silently downstream and present as application bugs.
- How can I verify a masked dump will not leak production data before sharing it?
- Scan the dump for canary values seeded into known production rows, and check the dump tail and row counts rather than just the process exit code, failing CI when either check trips. Faker output can violate enum, CHECK, VARCHAR, or unique constraints and kill the dump mid-INSERT, leaving a partial file that looks complete.
- Can I use masked dumps for CI fixtures, staging refreshes, or demo tenants?
- Yes, that is the intended use case: local development, CI fixtures, staging refreshes, demo tenants, and bug reproduction without handing over production secrets. Adoption risk stays confined to the data-provisioning workflow, but someone must own the column inventory and keep it current as the schema changes.
- What are the alternatives to laravel-masked-db-dump, and is it production-ready?
- Its realistic competitor is mysqldump plus an informal remember-to-sanitize checklist nobody runs; it is not a replacement for a commercial data-masking platform with classification, approval, retention, and audit trail. It is MIT-licensed from a single vendor, Beyond Code, with no commercial support or security review packet, and it covers masking only. Treat it as one half of a data-privacy control and budget days to weeks for the column inventory.
Weaver
How can I help you explore Laravel packages today?