Shows comprehensive status of PhoenixKit installation.

This task provides a detailed overview of your PhoenixKit installation status, including version information, database connectivity, assets status, and suggested next actions.

Usage

$ mix phoenix_kit.status
$ mix phoenix_kit.status --prefix=myapp

Options

• --prefix - Database schema prefix. When omitted, resolves from config :phoenix_kit, :prefix, then defaults to "public".
• --verbose - Show detailed diagnostic information
• --exit-code - Exit non-zero unless Next is Ready. For deploy scripts and CI, which otherwise cannot tell a clean install from a module sitting four versions behind — the report is identical on stdout either way. Off by default so existing deploys that run this for its log line keep passing.

Examples

# Show status for default installation
mix phoenix_kit.status

# Show status for custom schema prefix
mix phoenix_kit.status --prefix=auth

# Show detailed diagnostic information
mix phoenix_kit.status --verbose

# Fail a deploy when core or any module schema is behind
mix phoenix_kit.status --exit-code

Sample Output

PhoenixKit v1.7.216
├── Installed: V159 ✅
├── Database: Connected ✅
├── Modules: 2 modules, all up to date ✅
│   ├── Boards: V01 ✅
│   └── Inbox: V01 ✅
└── Next: Ready

The Modules row covers PhoenixKit modules that own their migrations (PhoenixKit.Module.migration_module/0) — each reports the schema version installed in your database against the version its code expects. When one is behind, the report says so and Next points at the fix and the reason:

PhoenixKit v1.7.230
├── Installed: V159 ✅
├── Database: Connected ✅
├── Modules: 2 modules, 1 behind ⚠
│   ├── Boards: V01 ✅
│   └── Inbox: V01 ⚠ (code expects V02)
└── Next: mix phoenix_kit.update — module schema behind: Inbox

The row is omitted entirely when no installed module owns migrations, so a core-only install keeps the compact tree.

"code expects", not "update available"

Everything reported here is measured against the version compiled into the running release — this task never asks Hex what exists, so it cannot and does not tell you a newer PhoenixKit is out. A version gap is therefore not an optional upgrade being offered; it means the schema disagrees with the code already querying it, which surfaces as runtime errors on whatever the newer version added. The wording is deliberate:

├── Installed: V159 ⚠ (code expects V160)
└── Next: mix phoenix_kit.update — database is V159, code expects V160

When core and a module are both behind, one command fixes both and both reasons are listed, so re-running does not turn up a second finding that was already knowable:

└── Next: mix phoenix_kit.update — database is V159, code expects V160; module schema behind: Inbox