Refresh Your Laravel Database Without Dropping Every Table

Laravel's built-in migrate:fresh drops every table before re-running your migrations, which is exactly what you want until it isn't. If a table holds seed data you don't want to regenerate, or test accounts you'd rather not recreate after every change, the all-or-nothing behaviour gets in the way. Custom Fresh, by Mahmoud Ramadan, adds a fresh:custom command that rebuilds the database while preserving the tables you name.

Choosing Which Tables Survive

Say you're building a subscription billing app and iterating on the schema all day, but you don't want to lose your test accounts or the seeded plans data on every refresh. You can name the tables to keep as a comma-separated argument or use the --keep flag. Both forms do the same thing:

php artisan fresh:custom users,plans

php artisan fresh:custom --keep=users,plans

Everything else is dropped, and the migrations run again, so the tables you list keep their rows while the rest of the schema is rebuilt from scratch.

Glob Patterns for Grouped Tables

Cashier alone creates subscriptions and subscription_items, and listing each one by name gets tedious. Custom Fresh accepts glob patterns, so a trailing wildcard matches any table sharing a prefix:

php artisan fresh:custom "users,plans,subscription_*"

Previewing Before You Commit

Because this command is destructive, you can ask it to report what it would do without touching the database. The --explain flag prints the tables it would keep and drop:

php artisan fresh:custom users,plans,subscription_* --explain

You can also point the command at a specific connection with --database, which is handy when some data lives in a separate database:

php artisan fresh:custom monthly_revenue --database=analytics

Screenshot showing fresh:custom command — Screenshot showing the Artisan command `fresh:custom` dry run with `--explain` and also running it without a dry run

Configuration and Events

Publishing the config file lets you set defaults instead of passing the same flags on every run. Tables in always_keep survive automatically, patterns applies your glob rules without spelling them out each time, and confirm_in lists the environments where the command pauses for a confirmation prompt before it drops anything:

return [
    'always_keep' => ['users', 'plans'],
    'patterns'    => ['subscription_*'],
    'confirm_in'  => ['staging', 'production'],
];

The command also dispatches three events during a run, which you can listen for to log activity or trigger follow-up work: RefreshingDatabase before any tables are dropped, TablesDropped after the removal step, and DatabaseRefreshed once the migrations finish.