BusDK Update

One command brings up the whole Bus stack: declarative service profiles

BusDK services can now be started from declarative service profiles. The early stack describes typed profile parameters, chooses a default startup set, includes an Events relay, and exposes a bus services ps view for inspection.

The value is self-hosting operability: the platform behaves more like one coherent stack that an operator can stand up, inspect, and stop from the same services surface.

June 2, 2026services stackservice profilesself-hosting

In brief

TL;DR

Declarative service profiles describe the Bus services stack as named profiles with typed parameters.
A default startup set can bring up the core local services together, including the Events relay in the same stack.
bus services ps gives operators a compact view of service state while the stack is running.

The services stack work moved BusDK away from treating local services as separate one-off commands. Profiles now give the stack a declarative shape: each profile can describe the service command, required parameters, environment passthrough, path handling, and role grouping that the dispatcher needs in order to launch it consistently.

That does not make the stack finished or production-hardened. It is still early and experimental, with the usual local-environment sharp edges. The important change is that the control plane has a typed place to describe service startup instead of relying on scattered shell knowledge.

The default set is meant to make the common local path boring: start the services surface, bring up the expected local components, and include the Events relay alongside them. That matters because Events is part of the platform behavior, not a side channel operators should have to remember to start by hand.

$ bus services up          # bring up the default stack
$ bus services ps
----------------+----------+-----------------+
| SERVICE        | STATE    | ENDPOINT        |
+----------------+----------+-----------------+
| events-relay   | running  | localhost:8081  |
| app-server     | running  | localhost:8080  |
| worker-manager | starting | localhost:8090  |
+----------------+----------+-----------------+

The bus services ps view is the operator-facing check that closes the loop. After startup, it shows which services the stack knows about and the state reported for each one. The output is intentionally compact: enough to answer whether the local stack is alive without turning service inspection into a separate debugging session.

For self-hosting, this is a useful maturity step. A developer or operator can ask the same services surface to start the default stack and then inspect what is running. The design still leaves room for profile-specific configuration, but the everyday path is one stack with one inspection command.

See docs.busdk.com for Bus services configuration and operation.