A rolling Linux distribution maintained with an integrated AI engineering system.

Development preview access is open for technical evaluation.

Bus Engine OS now has an accepted virtual-server image profile for technical evaluation. The first preview is still a continuously updated development channel, not a production support channel, and it does not include a production uptime SLA.

What Bus Engine is

Bus Engine provides the blueprints, agent tools, deterministic build operations, isolated execution environments, validation workflows, and lifecycle tooling used to build Bus Engine OS. It connects requirements, source code, target inventories, logs, tests, package definitions, kernel configuration, image construction, and validation evidence into one maintained system workflow.

Bus Engine OS is the rolling Linux distribution being built through that system. A disk image is one output. The durable asset is the versioned system blueprint that records what the system must do, how it is configured, how it is built, and how it is tested.

How you use it

The normal path is command-driven. Build the default server image, promote the accepted artifacts into the local Engine catalog, start the runtime, check its status, and open SSH into the guest.

bus engine os build image
bus engine os artifact promote-engine
bus services up
bus engine start
bus engine status
bus engine ssh

The build command detects the host architecture and CPU count, creates an isolated build workspace, builds or restores required package archives, assembles the root filesystem, creates QEMU image artifacts, and runs the image acceptance path. macOS arm64 hosts use Docker for the Linux build environment. Linux 64-bit hosts use the local build host when preflight passes and can fall back to Docker when Docker is available.

Why Bus Engine?

Use Bus Engine when the operating system itself has to be engineered around a workload. A general-purpose distribution gives a broad starting system. Many existing platforms can run that system in a virtual machine. The difficult work begins when the product needs specific kernel capabilities, package definitions, services, boot files, update behavior, and tests that prove the next image still works.

In a conventional VM workflow, those decisions often drift into shell history, hand-edited files, package notes, and an image that becomes difficult to rebuild. Bus Engine keeps them in a versioned system blueprint that can be inspected, rebuilt, booted, tested, and revised.

The integrated AI agent investigates the workload and target environment, configures the kernel and userspace, builds packages and system images, boots and tests the result, diagnoses failures, and updates the system through a rolling development process.

Deterministic tools perform compilation, dependency resolution, packaging, image construction, checksums, installation, and testing. The AI handles engineering work that cannot be reduced to fixed rules.

Component fixes follow the same model. When a component can legally be patched by the customer, Bus Engine is designed to carry that change in the blueprint, rebuild the affected package or image, and validate it without waiting for a general-purpose distribution to accept the change upstream. Upstreaming can still be the right long-term maintenance path.

When Bus Engine is the right choice

Bus Engine is appropriate when the operating system is part of the product, the workload needs a purpose-built environment, kernel or package engineering is required, or the system must be reconstructed from a maintained blueprint.

It is also useful when AI-assisted maintenance and diagnosis provide value, virtualized and customer-defined target profiles must be maintained, or hosted and locally operated AI models must both be supported by policy. Bus Engine OS is also being explored as a WASM-delivered target for browser-hosted evaluation workflows where a full VM is not the right first surface.

When another solution is simpler

Bus Engine is not necessary for every Linux virtual machine. A mature general-purpose Linux distribution is usually the simpler choice when standard packages and defaults already meet the requirement, no custom kernel or package engineering is needed, and the organization is comfortable maintaining the system through conventional administration.

Bus Engine becomes valuable when the operating system is part of the product or engineering problem: it must be specialized, built, tested, explained, and continuously adapted around a defined workload.

Organizations needing a production-ready general-purpose Linux system today should use an established distribution. The founding development preview is for evaluators who specifically want to participate in developing and testing the AI-maintained operating-system model. Commercial engineering and support can be purchased to help harden, validate, and maintain Bus Engine OS for a specific customer use case; production readiness depends on the agreed target, tests, operations, and support terms.

What a Linux distribution means here

In Bus Engine, a Linux distribution means the complete, versioned collection of system blueprints, kernel configurations, source inputs, patches, package definitions, compiled packages, boot files, filesystem and image definitions, services, update and recovery mechanisms, validation tests, and release artifacts needed to produce and maintain a runnable Linux operating system.

Who it serves

Initial use cases

Example: from source URL to system build

A team has an application that should run as a small server image with one service, a private package, a specific kernel feature, and a boot test. With a conventional VM, an administrator installs a distribution, tries packages, edits service files, records notes, and hopes the next rebuild follows the same path.

The Bus Engine workflow is designed around giving the agent the source URL, target profile, and acceptance tests. The agent inspects the source and build files, determines package, service, and kernel requirements, updates the system blueprint, creates or changes package definitions, and asks deterministic tools to build the package, assemble the image, boot it, and run tests.

Failed builds and failed boots feed back into the same loop: the agent reads logs and test evidence, changes the blueprint or package definition, and runs the controlled build again. The output is a maintained definition of how the OS is built and verified, plus the generated image and package artifacts.

In the June 2026 development state, the Engine runtime control path, artifact catalog, local VM provider path, QEMU integration, source-built package pipeline, virtual-server image generation, boot acceptance, and local artifact promotion are available. Update, recovery, rollback, GUI profile completion, and the complete source-URL-to-system-build workflow remain active development work.

Targets and support

Virtualized targets are the initial supported environment. Customer-defined hardware can be configured with Bus Engine or enabled through paid engineering support.

Current development status

AI and model access

Bus Engine integrates a separate agent-runtime component with Linux-specific tools, policies, blueprints, build environments, target information, logs, and validation workflows. The agent loop connects to a customer-selected hosted or local model provider.

Third-party hosted-model usage and AI service fees are not included unless a plan explicitly says otherwise. Customers may use supported hosted providers or compatible local model infrastructure where the deployment and policies support that model. The architecture page describes the Bus Engine agent-runtime boundary. The current runtime integration uses Codex App Server.

Software and source licensing

Bus Engine OS combines components under multiple licenses. Open-source components remain under their respective licenses. Bus-owned operating-system integration modules are provided under their published source-access terms, such as the Functional Source License where applicable. Proprietary BusDK userspace products remain subject to their commercial licenses.

For current founding plans, FSL covers only Bus-related code licensed by us. Monthly access includes the Bus Engine product-line codebase under FSL, with covered versions converting to MIT or Apache 2.0 after two years. The one-time option includes the current Bus Engine product-line codebase under MIT or Apache 2.0 at purchase, plus one year of FSL-licensed updates.

Bus Engine does not promise public source-code publication. For customer downloads, corresponding source for GPL, LGPL, MPL, and similar covered components is provided to the binary recipients through the customer release area at no extra charge, together with notices, license texts, patches, and build materials required for that release.

Founding offer

The founding offer is a named-operator development-preview program for people who directly administer or customize Bus Engine. It includes unlimited systems for that named operator, pre-production development access, best-effort support, and a 1 TB Bus Engine Persistent Storage allocation for supported BusDK-hosted virtualized systems, subject to the applicable commercial and service terms.