ποΈ Platform Engineering with TunaOS
TunaOS is built for platform engineers. Every aspect β from the immutable bootc foundation to the tooling ecosystem β is designed to make infrastructure reliable, reproducible, and manageable at scale.
Why TunaOS for Platform Engineeringβ
| Need | TunaOS Solution |
|---|---|
| Immutable OS | Bootc images β atomic updates and rollbacks |
| Reproducible builds | Container-native images built from Containerfiles |
| Fleet management | bootc switch / bootc upgrade across machines |
| CI/CD | GitHub Actions build pipeline with OCI registry |
| Developer tooling | Homebrew pre-installed, Tavern GUI, Bluefin CLI |
| VM management | Corral β QEMU/KVM and KubeVirt backends |
| USB provisioning | Tacklebox β multi-boot media creation |
| GPU workloads | GDX variants with NVIDIA/CUDA |
| Desktop choice | GNOME, KDE, COSMIC, Niri, XFCE |
Immutable Infrastructureβ
TunaOS uses bootable containers (bootc) β the same image-based approach as OpenShift CoreOS:
# Every machine runs from an OCI image
sudo bootc status
# Updates are image pulls + reboots
sudo bootc upgrade && sudo systemctl reboot
# Rollback is one command
sudo bootc rollback && sudo systemctl reboot
This means your entire fleet is defined by a container image digest. No configuration drift, no snowflake servers.
CI/CD Pipelineβ
TunaOS images are built in GitHub Actions and published to ghcr.io. The pipeline:
- PR β build test image β run smoke tests
- Merge to main β build all variants β push to registry
- Tagged release β build + sign + push + create GitHub release
You can fork this pipeline for your own custom images. See Building TunaOS and CI/CD for details.
Fleet Managementβ
Manage multiple machines with bootc:
# SSH into each machine and update
for host in dev-box-1 prod-box-1 prod-box-2; do
ssh "$host" "sudo bootc upgrade && sudo systemctl reboot"
done
# Pin all machines to the same digest
for host in prod-box-1 prod-box-2; do
ssh "$host" "sudo bootc switch ghcr.io/tuna-os/yellowfin:gnome@sha256:abc123..."
ssh "$host" "sudo systemctl reboot"
done
Developer Workstationsβ
Provision consistent developer environments:
# Each developer switches to the team's custom image
sudo bootc switch ghcr.io/my-org/dev-image:latest
# Pre-installed tooling via Brewfile
brew bundle install --file team.Brewfile
# Local VMs with Corral
corral create dev-env --qemu --container-disk quay.io/containerdisks/fedora:42
corral ssh dev-env
Provisioning USB Media with Tackleboxβ
Create multi-boot USB drives for on-prem provisioning:
# Recipe with multiple TunaOS variants + diagnostic tools
tacklebox build recipe.json --img provisioning.img
sudo dd if=provisioning.img of=/dev/sdX bs=4M status=progress
See the Tacklebox Getting Started guide.
VM Infrastructure with Corralβ
Manage VMs across laptop and cluster with one tool:
# Local dev VM
corral create dev --qemu --container-disk quay.io/containerdisks/fedora:42
# Production VM on Kubernetes
corral create web --kubevirt --container-disk quay.io/containerdisks/fedora:42
# Same commands, same workflow
corral ssh dev
corral ssh web
See the Corral Getting Started guide.
Securityβ
- Atomic updates β no partial update states
- Image signing β all TunaOS images are signed with cosign
- SBOM β software bill of materials generated per image
- Immutable
/usrβ system files cannot be modified at runtime - User data in
/varand/etcβ clean separation of OS and data
Monitoringβ
# Check deployment status across machines
bootc status --json
# Monitor update availability
systemctl status bootc-fetch-apply-updates.timer
# View boot logs
journalctl -b -o short-monotonic
See Alsoβ
- Managing with Bootc β day-to-day bootc operations
- CI/CD Pipeline β how TunaOS images are built
- Building Custom Images β creating derivative images
- Corral Guide β VM management
- Tacklebox Guide β multi-boot media
- Homebrew Guide β developer tooling