BusDK module CLI reference

How to read the module pages

This section explains what each BusDK module is for, when you usually use it, and which command to try first. Command names follow CLI command naming. Most pages show a short synopsis and a few practical examples first; for the full flag list, run the command-form help for the module, such as bus api --help, bus api provider llm --help, or bus operator stripe --help. The adjacent aiz tool uses its own aiz --help command.

The adjacent aiz toolchain is documented here too. It is not dispatched through bus, but it follows the same deterministic CLI style for single-file .aiz compression and offline restore with unaiz.

If you are building or operating an AI product

BusDK’s AI product surface is a set of cooperating modules rather than one monolithic server. Start with bus-api for the API host, bus-auth and bus-api-provider-auth for login and scoped tokens, bus-api-provider-llm for OpenAI-compatible model proxying, bus-api-provider-vm and bus-api-provider-containers for runtime status and container runs, and bus-events with bus-api-provider-events for request/reply and replayed event streams.

Operational product controls are split into focused modules. bus-billing, bus-api-provider-billing, bus-integration-billing, bus-integration-stripe, bus-integration-usage, and the bus operator family cover entitlement, checkout, usage export, internal catalog work, service-token operations, and deployment automation. Deployment-specific work uses bus operator deploy as a controller over focused cloud, database, node, and inference modules: bus operator cloud, bus operator database, bus operator node, and bus operator inference. Runtime-specific work uses bus-integration-containers, bus-integration-upcloud, bus-integration-docker, bus-integration-ssh-runner, bus-vm, and bus-containers.

Developer and agent workflows usually start with bus-agent, bus-dev, bus-integration-task, bus-run, bus-remote, bus-work, bus-secrets, and bus-shell. Browser-facing product surfaces are covered by bus-gx, bus-portal, bus-portal-auth, bus-portal-ai, bus-portal-accounting, bus-ui, bus-chat, bus-books, and bus-api-provider-terminal.

If you are starting a new workspace

Most users read these module pages in roughly this order:

  1. bus, bus-init, and bus-config to create a workspace and set company-wide defaults.
  2. bus-accounts and bus-period to define your chart of accounts and accounting periods.
  3. bus-files, bus-attachments, bus-bank, and bus-invoices to inspect incoming evidence files and bring source data into the workspace.
  4. bus-reconcile and bus-journal to connect source rows to accounting entries and maintain the ledger.
  5. bus-reports, bus-status, and bus-validate to review readiness, produce reports, and catch problems before close or filing.

If you need architectural background on why modules are independent and how they integrate, see Independent modules and Modularity.

For cross-module capability scanning, use the BusDK module feature table. It aggregates feature rows from each module repository FEATURES.md and shows user-visible capability, interface type, evidence, coverage, and maturity in one table.

Data files and paths

Workspace datasets use documented paths, usually conventional names at the workspace root such as accounts.csv, periods.csv, and datapackage.json. Use the module command or API documented for that dataset when you need to read, validate, or update it; this keeps path resolution, schema validation, and business rules consistent. The design allows future configuration of paths, for example in a data package, so end users can customize where data is stored without breaking how other tools discover it. bus-files is the deliberate exception in this list: it is a filesystem-facing parser/finder surface for local evidence files and does not start from a canonical workspace dataset.

Core entrypoints are bus, bus init, bus config, bus data, bus preferences, and bus status. Use these when you need to dispatch commands, initialize a workspace, maintain datapackage.json, inspect low-level datasets and schemas, or check workspace readiness.

Local interfaces are bus api, bus api provider billing, bus api provider books, bus api provider cloud, bus api provider containers, bus api provider data, bus api provider database, bus api provider inference, bus api provider llm, bus api provider mcp, bus api provider node, bus api provider session, bus api provider usage, bus api provider vm, bus billing, bus sheets, bus books, bus chat, bus gx, bus ui, and bus portal. They expose workspace data, assistant chat, provider adapters, billing setup, backend usage collection, model proxying, VM/container APIs, deployment operation APIs, and browser-facing UIs.

Automation and developer tooling live in bus dev, bus agent, bus run, bus remote, bus remote-control, bus work, bus update, bus secrets, bus shell, bus gateway, bus factory, bus events, bus lint, bus mcp, bus operator, bus operator auth, bus operator billing, bus operator cloud, bus operator database, bus operator deploy, bus operator inference, bus operator node, bus operator stripe, bus operator token, bus integration, bus integration billing, bus integration cloud, bus integration codex, bus integration containers, bus integration database, bus integration task, bus integration docker, bus integration inference, bus integration node, bus integration ollama, bus integration postgres, bus integration ssh runner, bus integration stripe, bus integration usage, bus integration upcloud, bus init, bus inspection, bus faq, and bus bfl. bus dev focuses on module-repository workflows, bus run focuses on local user-defined prompts/scripts/pipelines, bus remote resolves named hosted and local Bus platform endpoints, bus remote-control starts Codex remote control through the Bus dispatcher while keeping the local working-directory boundary explicit, bus work focuses on durable asynchronous work streams over Bus Events, and bus shell provides an interactive or one-shot command shell that dispatches through bus. These modules rely on bus-agent where agent runtime execution is required. bus secrets provides deterministic secret reference storage and resolution for step-level environment configuration. bus gateway, bus factory, the API/provider modules, operator modules, and event-driven integration workers support integration and service composition around the same workspace data.

Accounting domain modules are bus ledger, bus accounts, bus balances, bus debts, bus entities, bus customers, bus vendors, bus period, bus files, bus attachments, bus invoices, bus memo, bus journal, bus bank, bus reconcile, bus assets, bus loans, bus inventory, bus payroll, and bus budget.

Reporting, quality, and filing modules are bus reports, bus replay, bus validate, bus vat, bus pdf, bus filing, bus filing prh, and bus filing vero.

All current top-level modules in this superproject have matching end-user pages under this reference section, including supporting modules that are less often part of the first accounting workflow pass such as bus auth, bus billing, bus chat, bus containers, bus events, bus gateway, bus gx, bus inspection, bus operator, bus portal, bus preferences, bus remote, bus shell, bus status, bus ui, bus vm, and bus work.

← Year-end close (closing entries) Module CLI reference aiz →

Sources