Skip to content

CasadoraOS

Image-based Linux for home infrastructure.

A small family of bootc images for the machines that quietly run your home — single-board computers, hypervisor guests, CI runners. Built declaratively, updated atomically, owned by you.

Browse images Read the docs

What is CasadoraOS

CasadoraOS is a set of bootc images tailored for homelab and personal infrastructure roles. Each image is a Containerfile — a small, auditable definition you can read end-to-end in a few minutes.

The images target specific jobs rather than general use. Orion runs on a Raspberry Pi as an always-on services host. Proxima runs as a Proxmox guest, doing CI builds and acting as a remote build machine. New targets are added as they earn their place.

If you maintain your own infrastructure and you've outgrown hand-configured Debian boxes but found NixOS heavier than you wanted, this is the middle path: declarative Containerfiles, OCI distribution, atomic rollbacks, and a Linux you already understand underneath.

Images

  • Orion  stable

    aarch64 · raspberry pi 4/5 · sd/usb image

    Always-on services host for the home — the box that runs the things you don't want to think about.

    Includes Cockpit on :9090, Tailscale, Podman with rootless quadlets for user services, and the RPi-specific kernel and firmware bits handled at build time.

    Containerfile Latest image Install guide

  • Proxima  beta

    x86_64 · proxmox guest · qcow2

    Build and CI host — a remote workstation for producing the rest of the CasadoraOS images and running self-hosted automation.

    Includes a self-hosted GitHub Actions runner (quadlet), the full buildah/skopeo/qemu-user-static toolchain, Cockpit on :9090, Tailscale, and serial console wired up for qm terminal.

    Containerfile Latest image Install guide

How it works

Each image is built with bootc-image-builder from a Containerfile in this repo. The output is an OCI artifact for bootc switch, plus a disk image (qcow2 or RPi-flashable) for first install. Updates are pulled as new container images — no package-by-package drift, no half-applied state. If an update breaks something, bootc rollback puts you back where you were on the next boot.

Built on

bootc · Podman · systemd · Tailscale · Cockpit

Principles

No telemetry. The images don't phone home, and they never will.

No accounts. Nothing in CasadoraOS asks you to sign up for anything to use it.

No paid tiers. The image you build is the image everyone else builds.

Built in the open, built to be forked. Every image is produced by public CI from a Containerfile you can read in one sitting, and the build system is designed to accept your targets alongside ours.

Your hardware, your data, your call.

Getting started

Pull the latest Orion image onto a running bootc system:

sudo bootc switch ghcr.io/CasadoraTech/casadora-os/orion:latest
sudo systemctl reboot

Import a Proxima qcow2 into a Proxmox host:

qm create 9000 --name proxima --memory 8192 --cores 4 --net0 virtio,bridge=vmbr0
qm importdisk 9000 proxima.qcow2 local-lvm
qm set 9000 --scsi0 local-lvm:vm-9000-disk-0 --boot order=scsi0 --serial0 socket

Full instructions, including first-boot configuration and Tailscale enrollment, live in the install guides.

FAQ

Why not just use stock Fedora IoT or CoreOS?

You can, and they're excellent. CasadoraOS is what you get when you take Fedora bootc as a base and pre-decide the boring questions for a specific role: which user exists, where Tailscale lives, how Cockpit is exposed, which quadlets ship by default, what the serial console looks like. The images are short, readable Containerfiles — fork one if your answers differ.

Why bootc and not NixOS?

NixOS is the right answer if you want every package and config expressed in one language and you're willing to learn that language. bootc is the right answer if you want the image to be the unit of declaration — built with a Containerfile you already know how to read, distributed over OCI registries you already use, rolled back atomically when something breaks. CasadoraOS bets on the second path being enough for most home infrastructure.

Is this stable enough to actually run?

Orion has been running production home services for over six months and builds CasadoraOS itself — we dogfood every image. stable on the card means exactly that. Proxima is newer and marked beta until it's earned the same trust. Neither image is a research artifact, but both assume you can read a Containerfile and recover a machine if something goes sideways.

How do updates work?

bootc upgrade pulls the latest image from the registry, stages it as the next boot, and leaves the current deployment intact. Reboot to switch over; bootc rollback if it doesn't go well. There's no package-by-package drift, no half-applied state, no "did I remember to run that one Ansible playbook" — the running system is exactly the image, or it's the previous image.

Can I fork it for my own setup?

Yes — that's the expected path for anyone whose needs diverge. The Containerfiles are short on purpose so a fork stays maintainable. The build script (build.py) accepts new targets via a --target flag, so adding your own image alongside Orion and Proxima is mostly a matter of writing a new Containerfile.

What hardware is supported?

Whatever the underlying Fedora bootc base supports, minus anything CasadoraOS hasn't tested. Today that's Raspberry Pi 4/5 (Orion) and x86_64 Proxmox guests (Proxima). Other aarch64 SBCs and bare-metal x86_64 will likely work with a Containerfile tweak; they're just not images we ship.

What's the license?

The Containerfiles, build tooling, and site are open source — see the repo for the exact terms. The base images inherit Fedora's licensing.