Questions about Bus Engine and Bus Engine OS.

Product

What is Bus Engine?

Bus Engine provides the blueprints, AI-powered engineering tools, deterministic build operations, isolated execution environments, validation workflows, and lifecycle tooling needed to create and maintain custom Linux systems.

What is Bus Engine OS?

Bus Engine OS is the rolling Linux distribution being built and maintained through Bus Engine. Its accepted current profile is virtual-server, a minimal QEMU/KVM server image built from verified source inputs, assembled from validated Bus package archives, and boot-tested in QEMU. A browser-hosted WASM version is also in development for evaluation, demos, and distribution experiments. It is still a development-preview operating system, not a production-supported general-purpose distribution.

What does “Linux distribution” mean here?

It means the complete versioned collection of 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.

Why not just install an ordinary Linux distribution in a virtual machine?

You can, and that is the right choice for many general-purpose systems.

A general-purpose distribution gives a broad starting system. Bus Engine is intended for cases where the operating-system decisions are part of the product: kernel capabilities, package definitions, services, boot process, image construction, tests, update behavior, and lifecycle policy must be maintained together.

Its integrated agent can investigate requirements, create and revise the blueprint, build the resulting system, diagnose failures, and maintain it as the workload and upstream components change. The virtualization layer provides the machine. Bus Engine provides the operating-system engineering lifecycle.

Can Bus Engine package software from a source URL?

That is a core workflow Bus Engine is being built to support. The intended flow is to provide a 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.

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. The complete source-URL-to-system-build workflow remains active development work.

How does Bus Engine help with component fixes?

When a component can legally be patched by the customer, Bus Engine is designed to carry that change in the system blueprint, rebuild the affected package or image, and validate it through the same boot and test evidence. That can let a team move on its own maintenance schedule while a fix is proposed upstream or carried as a customer-specific patch.

Is Bus Engine only a package manager?

No. Package construction and dependency work are part of the lifecycle, but Bus Engine also covers requirements, kernel configuration, boot, services, filesystem and image shape, validation, diagnosis, and maintenance.

Does Bus Engine only configure the kernel?

No. Kernel configuration is one important area. The blueprint also covers userspace packages, services, boot, storage, networking, image outputs, validation, and lifecycle policy.

Status and releases

Is Bus Engine OS complete in the June 2026 development state?

It is complete enough for the accepted virtual-server development profile: the source-built package pipeline, package-built root filesystem, Linux kernel artifact, QEMU image artifacts, boot acceptance, OpenSSH startup, and local Engine SSH proof exist for that profile.

It is not complete as a production operating-system product. Update, recovery, rollback, production release operations, production support guarantees, broader hardware validation, the GUI profile, and the WASM version remain development work.

Which host platforms are supported now?

The documented build flow currently supports macOS arm64 and Linux 64-bit operator hosts. macOS uses Docker for the Linux build environment. Linux uses the local build host when preflight passes and can fall back to Docker when Docker is available.

Which image profiles exist now?

virtual-server is the accepted minimal QEMU/KVM server profile. virtual-desktop is an additive desktop profile under development and must not be treated as the accepted server image. A WASM version is also under development and is not yet part of the accepted server-image profile.

How do I build and run the accepted profile?

Use the default image build, promote the accepted artifacts into the local Engine catalog, start the runtime, check status, and then open SSH.

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

What artifacts does the build produce?

The accepted image workspace contains the assembled root disk, architecture-specific kernel image, rootfs tarball, QEMU artifact metadata, build provenance, image acceptance evidence, checksums, and validated package archives. Promotion copies stable local handles and updates the Bus artifact catalog records used by the Engine runtime.

How does preview access work?

Preview users receive rolling pre-production development builds as the operating system and tooling evolve. The preview binary lets evaluators use the Bus Engine OS tooling, while complete tested Linux distribution source access is limited to paid users under the applicable source-access terms.

How do rolling releases work?

The development channel receives continuously updated builds and evidence as the blueprint, package set, kernel work, build pipeline, validation, and maintenance workflows change. The first preview is not a version 1.0 release.

Is the development preview production-ready?

No. Organizations needing a production-ready general-purpose Linux system today should use an established distribution. The founding development preview is for evaluators who 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.

AI and agent runtime

How does AI participate?

AI performs adaptable engineering work: understanding requirements, interpreting evidence, selecting a configuration strategy, diagnosing failures, and updating the blueprint. Deterministic tools compile, package, build images, calculate checksums, boot, and test.

What is the agent runtime?

Bus Engine currently integrates Codex App Server as a separate open-source agent-runtime component, then combines it with Linux-specific tools, policies, blueprints, build environments, target information, and validation workflows.

Does Bus Engine use a REST API to communicate with the agent runtime?

No. Codex App Server uses bidirectional JSON-RPC 2.0. Bus Engine may expose its own HTTP APIs, but those APIs are Bus Engine APIs rather than the native App Server protocol.

Is the agent runtime included?

Bus Engine integrates Codex App Server as a separately licensed open-source runtime component. AI model access and hosted model service fees are configured separately.

Are AI model fees included?

Third-party hosted-model usage and AI service fees are not included unless a plan explicitly says otherwise.

Can customers use local models?

Customers may use a supported hosted provider or operate a compatible model within their own infrastructure where the deployed Bus AI integration modules, local-model integrations, policies, and network controls support that deployment.

Is the entire AI stack open source?

No. Codex App Server is an open-source runtime component, but selected hosted model services may be proprietary and separately billed. Local inference runtimes and models have their own licenses.

Targets, source, and storage

Can Bus Engine target physical hardware?

Virtualized targets are the initial supported environment. Customer-defined bare-metal servers, appliances, boards, and embedded systems can be configured by customers or enabled through paid hardware engineering.

Is arbitrary hardware certified?

No. Bus Engine enables hardware configuration; it does not automatically certify arbitrary hardware.

Which source code is included?

Source access is limited to the Bus Engine product-line codebase and release materials included in the applicable plan or agreement. The monthly plan uses the Functional Source License for Bus-related code and covered versions convert 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.

Third-party software remains under its own licenses. FSL applies only to Bus-related code licensed by us.

Which BusDK components remain binary-only?

Higher-level BusDK products and general proprietary userspace modules may remain binary-only where legally permitted by their own licenses and by the licenses of components they combine with.

Does a Bus Engine license include the full BusDK binary catalog?

The intended commercial model is to provide access to the complete BusDK binary release catalog while each Bus Engine OS blueprint installs only selected modules. Final checkout and license terms must confirm that entitlement before it is treated as a contractual deliverable.

Are all BusDK modules installed in every system?

No. Available means the entitlement permits access, installed means the binary is present in a specific image, and enabled means a service, listener, scheduled operation, or integration is active.

What does the 1 TB founder storage benefit include?

Founding Bus Engine customers receive a 1 TB Bus Engine Persistent Storage allocation for supported BusDK-hosted virtualized systems, subject to the applicable commercial and service terms. The detailed storage terms are finalized in the agreement.