Skip to main content

CLI Auth And Module Commands

This page covers the auth and module slices of the platform CLI.

Use these commands when you need to inspect the platform boundary itself, not just one customer app.

Auth Commands​

The platform exposes:

coil auth check
coil auth bindings inspect
coil auth test-model
coil auth list
coil auth lookup
coil auth explain
coil auth package validate
coil auth package inspect

auth check​

Use it to answer one practical question:

cargo run -p coil-cli -- auth check \
--config apps/shoppr/platform.dev.toml \
--subject user:alice \
--capability cms.page.publish \
--resource page:homepage

This checks the active auth package and runtime config, not just static schema files.

Use it after auth package validate and auth bindings inspect, not before them. That sequence tells you:

  • whether the package is structurally valid
  • how the stable capability maps into the current package
  • whether a concrete subject/resource check passes

auth bindings inspect​

Use it when you want to know how a stable capability maps into the current auth package:

cargo run -p coil-cli -- auth bindings inspect \
--config apps/shoppr/platform.dev.toml \
--capability cms.page.publish

This is the command to reach for when a module says “I need cms.page.publish” and you want to see how that stable capability is represented inside the active auth package.

auth package validate​

Use it before rollout or when changing auth files:

cargo run -p coil-cli -- auth package validate \
--config apps/shoppr/platform.dev.toml

Run this before:

  • release planning
  • cutover
  • changing auth schema files
  • switching auth packages in a customer app

Module Commands​

The platform exposes:

coil module list
coil module inspect <module>
coil module install <module>
coil module enable <module>
coil module disable <module>

module list​

cargo run -p coil-cli -- module list --config apps/shoppr/platform.dev.toml

Use this to see which modules the composed runtime knows about.

This is more useful than reading app.toml by hand because it shows the validated composed view after dependency and runtime checks.

module inspect​

cargo run -p coil-cli -- module inspect cms --config apps/shoppr/platform.dev.toml

Use this when you need module-level detail before changing app composition.

Typical questions this command answers:

  • what routes does this module add?
  • what capabilities does it require?
  • what dependencies does it declare?
  • what jobs or admin/operator surfaces come with it?

module enable And module disable​

These commands intentionally support dry-run and confirmation:

cargo run -p coil-cli -- module enable media \
--config apps/shoppr/platform.dev.toml \
--dry-run

and:

cargo run -p coil-cli -- module disable media \
--config apps/shoppr/platform.dev.toml \
--dry-run

That is the safe operator posture for composition-changing commands.

After any module change, use the customer binary as the next check:

cd apps/shoppr
cargo run -p shoppr -- validate

That proves the app still composes with its customer-owned templates, extensions, and linked backend.