BusDK Update
bus services now has a public product guide and a clearer operations story for running the self-hostable BusDK platform as managed services you control.
The June 18 work pairs that buyer-facing guide with service restart, locking, and liveness hardening, so evaluation can start from public material and continue into hands-on operation.
In Brief
For a prospective buyer, the important change is legibility. Bus Services is presented as the operating layer for bringing up the BusDK platform services, inspecting them, and keeping the stack understandable while evaluation is still open and hands-on. The guide gives the product a named place in the public surface without asking readers to infer the value from daemon names or local scripts.
A typical operator check stays intentionally direct:
$ bus services ps
NAME STATE HEALTH
bus-api running live
bus-events running live
bus-workers running liveThe operations work behind this post is practical hardening in the service layer. The module history for June 18 includes liveness hardening, restart guards, portable service lifecycle locking, event relay locking, and service token snapshot normalization. Those changes support the same operating model: a service stack should show what is alive, avoid overlapping lifecycle changes, and make restart behavior explicit.
The commercial path is also public. Pricing is available through the BusDK website and handled by Stripe there, while the documentation explains the product surface and the service commands. This post does not restate prices because checkout, terms, and current offers belong on the website and docs.
Bus Services is still an early, experimental product surface. The useful buyer signal is that the self-hostable platform now has an open guide, visible pricing entry points, and operations hardening that can be evaluated directly instead of treated as a private setup conversation.
See docs.busdk.com for the Bus Services product guide and operations details; pricing is on the website.