Do once
- Your application
- MariaDB
- Redis
- Observability
- Custom bootstrap
- …
Early development
Turn your software into a Kubernetes appliance
Start with a maintained, hardened kubeboot base. Define your product once, then deploy, update, and support it consistently across customer environments.
Without rebuilding the platform for every installation.
kubeboot Base Appliance
Operations & Bootstrap01
Kubernetes02
Hardened Linux03
bootc / OCI04
Maintained and released by kubeboot. Or rebuild it from the open-source code.
Per installation
- Deployment Configuration
- Networking
- DNS / NTP
- Access & keys
- Registry credentials
- Enabled services
- Product settings
Download configuration ISO
Your Product Appliance
- Virtual machine
- Kubernetes runtime
- Your application
Boot the VM. Attach the configuration. kubeboot prepares the system and deploys the product.
Deploy your product wherever your customers need it.
The same kubeboot product definition can be delivered across connected, on-premises, and isolated environments.
CLOUD
Cloud infrastructure
Run kubeboot as a virtual machine in cloud infrastructure while your application stays packaged and operated as Kubernetes workloads.
ON-PREMISES
Customer infrastructure
Deliver the same product appliance into the customer's virtualized environment with a predictable installation and operating model.
AIR-GAPPED
Isolated environments
Install and update without Internet access. Prepare the required OCI artifacts in advance and deliver them through offline media.
Scale your product, not your platform team.
Delivering Kubernetes software to customers means solving more than your application. It includes the operating system, Kubernetes installation, security, networking, registries, upgrades, troubleshooting, and repeatable deployment.
kubeboot standardizes that platform layer. Your team defines the product. kubeboot provides the common runtime and lifecycle around it.
What's inside kubeboot
Four layers provide the runtime and lifecycle around your product.
Runtime
Kubernetes runtime
A production-oriented foundation for single-node and high-availability deployments.
Podman
Container tooling for the appliance and its OCI workflows.
Local OCI Registry
A consistent artifact source that also enables disconnected operation.
Headlamp
A built-in web UI for inspecting and operating Kubernetes resources.
Security
Hardened Linux Base
A maintained operating-system foundation with secure defaults.
SELinux
SELinux is enforcing by default.
Network Hardening
Secure defaults reduce the infrastructure configuration needed at each installation.
Controlled configuration
Machine-specific state and credentials stay separate from the base appliance.
Bootstrap & Operations
Configuration-driven bootstrap
A bootstrap layer turns deployment configuration into a running system.
Extensible product bootstrap
Product overlays can provide initialization steps without changes to the base.
Operations CLI
Inspect status and perform common administrative tasks from one CLI.
Built-in troubleshooting
Open a debug session or temporary port forward without assembling Kubernetes commands.
kbt db forward
→ local connection detailsLifecycle
bootc (operating system)
The base OS is delivered and updated as a bootable OCI image.
Flux (desired state)
Flux connects the appliance to the vendor-managed product state.
Helm (application releases)
Product services use versioned Helm releases.
Release control
Each deployment can follow an explicitly approved product release.
Automated update workflow
Apply approved updates and complete a controlled reboot when required.
An appliance built like a container.
kubeboot uses bootc to build and maintain the operating-system layer as an OCI image. The base appliance can use familiar registry, versioning, and image-release workflows.
Why it matters
- One reproducible system image.
- Versioned releases.
- Registry-based distribution.
- Image-based updates instead of package drift.
OS Definition
- Containerfile
- System configuration
- Platform components
OCI Registry
- Versioned bootable image
- Signed release reference
kubeboot Base Appliance
Operations & Bootstrap01
Kubernetes02
Hardened Linux03
bootc / OCI04
VM Appliance → image-based update
Define your product once.
An overlay describes what a kubeboot appliance needs to add, configure, and operate a product component.
An overlay can include Helm releases, OCI artifact references, configuration defaults, validation rules, and product-specific bootstrap logic.
kubeboot Base Appliance
Operations & Bootstrap01
Kubernetes02
Hardened Linux03
bootc / OCI04
Product Overlays
- Your application overlay
- MariaDB overlay
- Redis overlay
- Observability overlay
- Other product dependencies
Your Product Definition
- Versioned component set
- Defaults & validation
- Bootstrap logic
Your overlays
Package the software and configuration that make your product unique.
Open-source overlays
Reuse maintained definitions for common infrastructure and open-source services.
Commercial overlays
Integrate licensed or private components through authenticated OCI registries.
Overlay Catalog will be available later on.
Keep the product definition separate from the customer configuration.
Define your product once. Configure each deployment.
Your product
Product Definition
- Application
- Dependencies
- Helm releases
- Bootstrap logic
- Validation
Customer environment
Installation Configuration
- Networking
- DNS / NTP
- Credentials
- Registry access
- Enabled options
kubeboot configuration
Configuration ISO
Start VM
Bootstrap + validation
Running product
This model lets implementation partners and operators configure a customer environment without requiring expertise in the full Kubernetes stack.
kubeboot runs the platform. You control the product.
Flux connects the vendor's desired product state to the running Kubernetes appliance.
Versioned Helm releases deliver applications and supporting services. kubeboot continues to provide the operating system, bootstrap, and operations foundation.
Vendor Git / OCI
desired state ↓
Flux
Helm Releases
Product workloads
↓
Kubernetes
kubeboot appliance
Update the whole product through controlled releases.
A release can define the exact operating-system image and product component versions approved for a deployment.
Approved Release
Base OS version→bootc / OCI
Application version→HelmRelease
MariaDB version→HelmRelease
Other overlays→OCI / Helm
Validate
Reboot when required
kubeboot retrieves the required artifacts, applies the approved release, and performs a controlled reboot when an operating-system update requires one.
Deployments can follow different approved releases. They do not have to consume every new version.
bootc = operating system
Flux + Helm = product workloads
Flux + Helm = product workloads
The same lifecycle, without an Internet connection.
Air-gapped environments do not need a second deployment model.
Initial installation
- 01Product Release
- 02Resolve required OCI artifacts
- 03Configuration + artifacts
- 04Configuration ISO
- 05Isolated kubeboot appliance
- 06Local OCI registry
- 07Bootstrap product
Resolve and package the required product artifacts with the deployment configuration before you enter the isolated environment.
Offline updates
- 01Approved Update
- 02OS image + overlay artifacts
- 03Update ISO
- 04Transfer to isolated environment
- 05Import into local registry
- 06Apply Helm + OS updates
- 07Controlled reboot
An Update ISO carries the approved OCI artifacts, including a new base OS image when required, into the isolated environment.
Built for the teams who operate and support your appliances.
kubeboot does not stop after installation. Common operational and troubleshooting workflows are part of the appliance.
See what is running
Inspect platform, bootstrap, and workload health from the CLI or the built-in Kubernetes UI.
Restart or rerun platform actions
Perform common appliance operations without reconstructing low-level Kubernetes commands.
Debug internal services
Create controlled temporary access to services such as databases through built-in troubleshooting workflows.
Inspect Kubernetes visually
Use the integrated Headlamp interface when a graphical view of resources and workload state is more useful.
Use our builds. Or own the whole build pipeline.
kubeboot is open source under the MIT License. Start with maintained base appliance releases, or build and publish the base yourself with the same open-source tooling.
Use maintained releases
Consume the published kubeboot base and focus on your product overlays.
Build it yourself
Rebuild the base from source, control your OCI registry, and own the complete release pipeline.
Help us keep building in the open.
kubeboot is part of the Distro Ops open-source and commercial ecosystem. Partners fund long-term development while the project stays available under its open-source license.
Partners
Visibility across the Distro Ops open-source ecosystem, including project websites, README files, and the central partner page.
Partner Slot #2
Partner Slot #3
Need to manage appliances at fleet scale?
kubeboot handles the lifecycle of the appliance itself. Distro Ops provides fleet management and centralized lifecycle control for teams that need to scale their product.
One product. Consistent deployments. Every environment.
Start with the kubeboot base, define your product overlays, and deploy your first appliance.