The vukem CLI

go install github.com/AlexGalhardo/vukem/cmd/vukem@latest
vukem list

vukem works on files and shells out to the standard Go toolchain; it never imports your code. Commands it does not know are handed to your app binary, so vukem migrate works like php artisan migrate.

Commands#

Flags may come before or after arguments: vukem make:model Post -m -c equals vukem make:model -m -c Post.

Generators#

• Generated Go is gofmted. Existing files are never overwritten without --force.
• Conventional suffixes are optional: PostController, BillingProvider and SendReportsCommand work as names.
• Registration edits the target file through its AST and adds imports; running a generator twice does not register twice. If the file was restructured, the generator prints the line to add by hand.

Custom stubs#

Stubs are text/template files embedded in the CLI. Put a file with the same name in your project's stubs/ directory to override one (controller.go.tmpl, model.go.tmpl, migration.go.tmpl, middleware.go.tmpl, request.go.tmpl, command.go.tmpl, provider.go.tmpl, factory.go.tmpl, seeder.go.tmpl, resource.go.tmpl, policy.go.tmpl, mail.go.tmpl, mail.html.tmpl, event.go.tmpl, listener.go.tmpl, job.go.tmpl, test.go.tmpl). Available data: .Name (Pascal), .Snake, .Kebab, .Camel, .Plural, .Module, and .Table, .Timestamp, .ID, .Func, .Resource, .API where relevant. Unknown keys are errors.

App commands#

Any other command runs inside your application:

vukem migrate
vukem migrate:status --json
vukem route:list
vukem queue:work
vukem schedule:list
vukem openapi:export > openapi.json
vukem about
vukem reports:send --dry-run   # your own command

vukem builds cmd/app into .vukem/bin/app and runs it with the same arguments. The binary is rebuilt only when a .go, go.mod or go.sum file is newer, so repeated commands start instantly. Built-in app commands: migrate, migrate:rollback, migrate:reset, migrate:fresh, migrate:status, db:seed, db:wipe, route:list, about, key:generate, queue:work, queue:failed, queue:retry, queue:forget, schedule:run, schedule:work, schedule:list, openapi:export, codegen:types, codegen:client, codegen:routes, ssr:start, ssr:check, boost:mcp and openapi:serve (when you add apidocs.Command()). Destructive commands need --force in production. Add your own with vukem make:command (see Application lifecycle).

Running the binary directly works too: go run ./cmd/app migrate.

APP_KEY without the global CLI#

Docker images and CI runners usually ship only your compiled binary, not vukem. The app's own key:generate prints a new key and never touches .env; it also works before any APP_KEY exists, since it runs without booting the app:

./app key:generate                    # base64:...
export APP_KEY="$(./app key:generate)" # use it in the current shell
docker run --rm my-app key:generate    # with ENTRYPOINT ["/app"]

Only the key goes to stdout; errors and -h output go to stderr, so a typo never ends up inside APP_KEY. Store the printed value in your secret manager or deployment environment. vukem key:generate (global CLI) is the one that writes .env.

The built-in key:generate always wins over an app command registered with the same name, because it runs before the app is built.

vukem serve#

• Builds to a separate file and swaps it in after the old process stops, so it works on Windows where a running .exe cannot be overwritten.
• A failed build prints the compiler errors and keeps the previous version running.
• Views reload inside the app on every request in development; editing a template needs no rebuild.
• When a vite.config.* exists, <pm> run dev runs alongside (disable with --no-vite).
• Package manager: serve, build and install:inertia use the one whose lockfile is in the project (bun.lock → Bun, pnpm-lock.yaml → pnpm, yarn.lock → Yarn), else npm. No configuration needed: run bun install once and the CLI follows.

Exit codes#

A delegated app command's exit code is passed through unchanged.