CLI reference

This is the manual for the vukem command. It lists every command, every flag, what each one writes to disk, the errors you may hit and how to fix them. Each command has a one-line purpose, a usage line, arguments, flags, and two examples: a realistic one and an advanced one. All output shown was captured from the real command.

For a guided tour with explanations and analogies, read the CLI overview. Use this page when you already know what you want and need the exact syntax.

You will find:

• A cheat sheet of all commands
• The global flags, environment variables and exit codes
• Common workflows, end to end
• Links to one reference page per command group

Command cheat sheet#

Commands marked global run in the vukem binary and work on files. Commands marked app run inside your project's cmd/app binary: vukem builds it and passes the arguments through (how delegation works).

Global flags#

These work on the vukem binary itself, before any command.

Per-command rules:

• Flags use Go's flag package: -force and --force are the same. --event=X and --event X are the same.
• On global commands flags may come before or after the arguments: vukem make:model Comment -m equals vukem make:model -m Comment.
• On app commands flags must come before positional arguments. db:seed is the exception: it reads seeder names first, then flags.
• -- ends flag parsing.
• Boolean flags do not combine: write -m -f -c, not -mfc.
• There is no --env, --quiet or --no-color flag. Output is plain text with no colour.

Environment variables#

The global CLI reads almost nothing from the environment:

Everything else is read by your app, from the process environment or the .env file in the project root. The ones the CLI commands rely on:

See Configuration for the full list.

Exit codes#

A delegated app command returns its own exit code unchanged. A bare vukem <unknown> is delegated too, so inside a project it prints the app's command list and exits 2.

How commands are found#

1. If the name is a global command, vukem runs it.
2. Otherwise vukem builds cmd/app into .vukem/bin/app and runs it with the same arguments, standard streams and environment. It rebuilds only when a .go, .templ, go.mod, go.sum or .buildtags file is newer than the binary.
3. Outside a project you get unknown command "migrate" (app commands need a Vukem project with cmd/app).

You may skip step 2 and run the binary yourself: go run ./cmd/app migrate.

Common workflows#

New API project#

vukem new shop --api --module github.com/acme/shop
cd shop
vukem migrate
vukem serve

Migrated: 20260101000000_create_posts_table
Migrated: 20261024221606_create_users_table
Migrated: 20261024221607_create_auth_tables

Then curl localhost:3000/up answers {"status":"ok"}. Check the routes with vukem route:list.

Add a resource end to end#

A Comment that belongs to the blog:

vukem make:model Comment -m -f -c
vukem make:request StoreComment
vukem make:policy Comment
vukem make:test Comments
vukem migrate

Fill the migration, the model fields and the controller, register the routes in routes/, then run go test ./.... For an API, use make:resource Comment for the JSON shape and vukem codegen:client for a client. See reference: make.

Seed and migrate#

vukem make:seeder Post
vukem migrate:fresh
vukem db:seed

migrate:fresh drops every table and migrates again, db:seed fills them. In production add -force on purpose and only after reading the guard.

Build for production#

vukem codegen:types -prefix /api -o resources/js/types.ts
vukem build -o bin/shop
export APP_ENV=production APP_DEBUG=false MAIL_MAILER=log
./bin/shop migrate
./bin/shop

vukem build runs templ generate and vite build when the project has them, then go build -trimpath -ldflags="-s -w" with CGO_ENABLED=0. The binary contains every app command, so a server without the vukem CLI still runs ./bin/shop migrate. In production the app refuses to boot without MAIL_MAILER (smtp, resend, mailtrap or log). See Single binary.

Reference pages#