The Nibiru CLI

The ./nibiru binary is a compiled command-line tool that ships in every Nibiru project. It scaffolds modules, controllers and plugins, runs migrations, manages the cache, and (with the CMS module) creates and deletes pages.

  _   _ _ _     _              ______                                          _
 | \ | (_) |   (_)            |  ____|                                        | |
 |  \| |_| |__  _ _ __ _   _  | |__ _ __ __ _ _ __ ___   _____      _____  _ _| | __
 | . ` | | '_ \| | '__| | | | |  __| '__/ _` | '_ ` _ \ / _ \ \ /\ / / _ \| '__| |/ /
 | |\  | | |_) | | |  | |_| | | |  | | | (_| | | | | | |  __/\ V  V / (_) | |  |   <
 |_| \_|_|_.__/|_|_|   \__,_| |_|  |_|  \__,_|_| |_| |_|\___| \_/\_/ \___/|_|  |_|\_\

All flags

Flag	What it does
-m {name}	Generate a new module named {name}. Add -g to wire Graylog logging hooks.
-c {name}	Generate a new controller {name} plus its template.
-p {name} -m {module}	Generate a new plugin {name} inside {module}. Add -g for Graylog.
-cache-clear	Clear application/view/templates_c/ and application/view/cache/.
-s	Bootstrap framework folders and fix permissions. Run once after install.
-mi {env}	Run migrations from application/settings/config/database/ against local, staging or production.
-mi-reset {env}	Drop the migrations audit table for {env}. Destructive.
-mi-reset-file {file} {env}	Forget that a single migration file ran for {env}.
-ws {URL} -wp {PORT}	Connect to a WebSocket at {URL}:{PORT} (interactive REPL).
-new-cms-page {name}	(CMS module only) Create a new CMS page bound to an existing template.
-delete-cms-page {name}	(CMS module only) Delete a CMS page.
-h	Show the help text.
-v / -version	Print the binary’s version and the framework version.

Daily commands you’ll actually use

# create a controller + view
./nibiru -c products

# create a module with Graylog hooks
./nibiru -m billing -g

# create a plugin inside that module
./nibiru -p invoices -m billing

# run migrations
./nibiru -mi local

# clear the Smarty cache after a deploy
./nibiru -cache-clear

# show framework version
./nibiru -v

Environments

Most commands honour APPLICATION_ENV:

APPLICATION_ENV=production ./nibiru -mi production
APPLICATION_ENV=staging    ./nibiru -mi staging

The trailing {env} argument to -mi selects the migrations target; both must match.

What the CLI is built on

The binary is a compiled C++ executable that links against MySQL, PostgreSQL (libpq) and ODBC client libraries. Conditional compilation means a binary built without libpq still works for MySQL-only deployments — graceful degradation rather than a hard dependency.

You’ll find the binary at the project root next to index.php. It’s executable out of the box (chmod +x nibiru if needed).

CI integration

A simple GitHub Actions step:

- name: Run migrations
  run: |
    APPLICATION_ENV=production ./nibiru -mi production
  env:
    DB_HOST: ${{ secrets.DB_HOST }}
    DB_USER: ${{ secrets.DB_USER }}
    DB_PASS: ${{ secrets.DB_PASS }}

The CLI exits non-zero if any migration fails, so CI will catch SQL errors.