CLI reference
The scaicontrol CLI is installed alongside the backend Python package (pip install -e . inside backend/ exposes it as a console script). It wraps three command groups: setup, sync, and admin.
1 2 | |
All commands read configuration from the same .env / environment variables that the backend reads — see Configuration. The CLI uses a synchronous DB connection (via pymysql), so DATABASE_URL is rewritten internally from mysql+asyncmy://… to mysql+pymysql://….
scaicontrol setup#
First-run bootstrap against ScaiKey. Registers ScaiControl as a ScaiKey application, polls until approval, and writes the resulting OAuth credentials back to .env.
setup register#
Submit a registration request to ScaiKey.
1 2 3 4 5 6 | |
| Flag | Required | Notes |
|---|---|---|
--scaikey-url, -k |
yes | Base URL of the ScaiKey instance |
--url, -u |
yes | Public base URL of this ScaiControl deployment (used as OAuth redirect_uri) |
--email, -e |
yes | Contact email for the registration |
--scope, -s |
no (default GLOBAL) |
One of GLOBAL, PARTNER, TENANT |
--partner, -p |
when scope=PARTNER | Partner slug |
--tenant, -t |
when scope=TENANT | Tenant slug |
--name, -n |
no (default ScaiControl) |
Application display name |
Writes a status token to ~/.config/scaicontrol/registration.json (mode 0600). The token is printed once — save it.
setup status#
Poll ScaiKey for the registration's approval state. On APPROVED, writes SCAIKEY_CLIENT_ID, SCAIKEY_CLIENT_SECRET, SCAIKEY_APP_ID, and SCAIKEY_ISSUER to the project .env file.
1 | |
States: PENDING, APPROVED, REJECTED. Run repeatedly until approved.
setup show#
Display current ScaiKey configuration (secrets masked).
1 | |
scaicontrol sync#
Pull users and groups from ScaiKey into the local database. Used to populate the users and groups tables for tenant-isolated query auto-filters and role assignments.
1 2 3 | |
Run this after setup status completes, then again whenever ScaiKey's user list changes materially (or schedule via cron). Idempotent — re-runs converge on the ScaiKey-side state.
scaicontrol admin#
User and role management on the local database. All admin operations are local-DB-only — they don't propagate back to ScaiKey. ScaiKey is the source of truth for identity; admin here manages ScaiControl-side role bindings on already-synced users.
admin list#
List active users in the local DB.
1 2 3 | |
--role filters by role; valid values: super_admin, partner_admin, tenant_admin.
admin grant#
Assign a role to a user.
1 2 | |
User can be identified by ID (positional) or --email. The role replaces any existing role on the user (single-role-per-user model).
admin revoke#
Remove a user's role. Errors if the user doesn't currently hold the named role.
1 2 | |
admin show#
Print a user's full local record (ID, email, name, tenant, partner, role, sync timestamp).
1 2 | |
admin find#
Search ScaiKey (not the local DB) for users by email or name substring. Useful for discovering a user before running sync.
1 2 | |
admin templates validate#
Compile every saved designer template (invoice + email) through Jinja and report syntax failures. Exits non-zero on any failure — suitable for CI.
1 2 3 | |
| Flag | Notes |
|---|---|
--name |
Filter by template name (exact match) |
--lang |
Filter by language code (e.g. nl, de) |
Validates both html_content and subject fields where present.
Exit codes#
| Code | Meaning |
|---|---|
| 0 | Success |
| 1 | Validation/runtime error (ClickException) — message printed to stderr |
| 2 | Usage error (UsageError) — typically a missing required option |
The admin templates validate command additionally exits 1 when any template fails to compile, regardless of whether other operations succeeded.
Common workflows#
First-run deploy:
1 2 3 4 5 6 7 | |
Promote a user to platform admin:
1 2 | |
Pre-deploy template smoke check (in CI):
1 | |