CLI reference: database

These commands change or read your database. They are app commands: vukem builds cmd/app, boots your app and runs the command inside it, so they use your .env. Back to the command cheat sheet.

Rules that apply to all of them#

• Flags go before positional arguments. db:seed is the exception (see below).
• Environment: DATABASE_URL (default file:storage/database.sqlite), DB_MAX_OPEN (10), DB_MAX_IDLE (5), APP_ENV, APP_DEBUG.
• The app boots before the command runs, so a boot error stops it first, with exit code 1 and a vukem: prefix. In production, APP_DEBUG=true is a boot error: vukem: APP_DEBUG must be false when APP_ENV=production.
• Output is one line per migration, in the order they ran.
• All of them print to standard output and use exit code 1 on failure.

The production guard#

migrate:reset, migrate:fresh, db:seed and db:wipe destroy or rewrite data. When APP_ENV=production they refuse to run unless you pass -force:

APP_ENV=production APP_DEBUG=false vukem migrate:fresh

refusing to run a destructive command in production without --force

Exit code 1, nothing changed. With -force it runs. migrate, migrate:rollback and migrate:status have no guard.

vukem migrate#

Run every pending migration, in timestamp order, as one new batch.

vukem migrate

No flags, no arguments.

vukem migrate

Migrated: 20261024221120_add_slug_to_posts_table
Migrated: 20261024221120_create_comments_table
Migrated: 20261024221145_create_users_table

Run again:

Nothing to migrate.

Writes to the migrations bookkeeping table (id, batch, run time). A migration that fails stops the run and returns its error with exit code 1.

Advanced: a different database for one run. The command reads DATABASE_URL from the environment before .env, so you may point one run elsewhere:

DATABASE_URL=file:storage/test.sqlite vukem migrate

Migrations are written with vukem make:migration. See Migrations.

vukem migrate:rollback#

Undo migrations, newest first.

vukem migrate:rollback [-step N]

vukem migrate:rollback -step 1

Rolled back: 20261024221206_add_billing_tables

Without -step, every migration in the last batch goes. After a fresh install all migrations share batch 1, so a bare migrate:rollback undoes all of them:

Rolled back: 20261024221607_create_auth_tables
Rolled back: 20261024221606_create_users_table
Rolled back: 20260101000000_create_posts_table

Each migration's Down runs, so data in dropped tables is lost. Check migrate:status before you run it in production.

vukem migrate:reset#

Roll back every migration, in reverse order.

vukem migrate:reset [-force]

Output: one Rolled back: <id> line per migration. Each migration's Down runs.

vukem migrate:fresh#

Drop all tables, then run every migration again.

vukem migrate:fresh [-force]

vukem migrate:fresh

Migrated: 20260101000000_create_posts_table
Migrated: 20261024221607_create_auth_tables

Everything lands in batch 1 again. The usual loop in development:

vukem migrate:fresh && vukem db:seed

vukem migrate:status#

Show which migrations ran and which are pending.

vukem migrate:status [-json]

vukem migrate:status

MIGRATION                                     STATUS   BATCH
20260101000000_create_posts_table             Ran      1
20261024221120_add_slug_to_posts_table        Pending  
20261024221120_create_comments_table          Pending  

With -json each entry has id, ran, batch and ran_at (UTC):

[{"id":"20260101000000_create_posts_table","ran":true,"batch":1,"ran_at":"2026-10-24T22:08:10.2232772Z"}]

Use it in CI to fail a deploy that has pending migrations.

vukem db:seed#

Run the seeders: classes that insert starting data.

vukem db:seed [Name...] [-class Name]... [-force] [seeder flags]

Arguments: zero or more seeder names, before any flag. With none, every registered seeder runs, in the order of All() in database/seeders/registry.go.

Interactions

• Names come first, then flags: vukem db:seed PostsSeeder -force. This is the one app command that reads names before flags, because the flags it accepts depend on the seeders you name.
• Flag names that several seeders define are shared: the seeders that run all receive the value.
• force, class, help and h belong to db:seed. A seeder that defines one of them is an error, so no seeder can bypass the production guard.
• make:seeder -app seeders (AppSeeder) receive the booted app. Register them with vukem.WithAppSeeders(seeders.AllApp()...).

vukem db:seed

Seeded: PostsSeeder
Seeded: TagSeeder

Errors

Advanced: pick seeders

vukem db:seed TagSeeder -class PostsSeeder

Runs TagSeeder and PostsSeeder. See Factories and seeders.

vukem db:wipe#

Drop every table, leaving an empty database. Unlike migrate:fresh it does not migrate again.

vukem db:wipe [-force]

vukem db:wipe

Dropped all tables.

After it, vukem migrate rebuilds the schema. Back up first in any shared environment.

Troubleshooting#