Fedora CoreOS review: immutable container OS for hands-off infrastructure

What CoreOS is and why it exists

Fedora CoreOS is a minimal, automatically updating Linux distribution designed exclusively for running containerized workloads at scale. It emerged in 2019 as the successor to both CoreOS Container Linux and Fedora Atomic Host, combining Ignition provisioning from the former with rpm-ostree package management and SELinux hardening from the latter. Unlike general-purpose server distributions, CoreOS provides only a Linux kernel, systemd, container runtimes Podman and Moby, and an SSH server—everything else runs in containers.

The system follows an immutable infrastructure model. The root filesystem is read-only in normal operation; only two directories are writable by default, /etc and /var. Configuration happens declaratively at first boot via Ignition, a provisioning tool that reads a JSON configuration file and partitions disks, writes systemd units, injects SSH keys, and configures users before the OS fully initializes. After provisioning, operators are discouraged from modifying the host; changes should instead trigger reprovisioning of replacement instances. This approach eliminates configuration drift and makes scaling trivial—launch additional machines with the same Ignition config.

CoreOS ships in three release streams: stable, testing, and next. Updates arrive automatically every two weeks via rpm-ostree and Zincati, the update agent. The OS downloads a new image, installs it atomically, reboots into it, and can roll back to the previous version if the update fails. Fedora CoreOS is entirely open source and free, maintained by the Fedora CoreOS Working Group and Red Hat engineers, and serves as the foundation for Red Hat OpenShift and OKD Kubernetes distributions.

Ignition provisioning: the first-boot-only gate

Ignition is the single biggest conceptual hurdle for anyone accustomed to traditional server administration. It runs during the initramfs phase of the very first boot, reads a configuration file from a remote URL, cloud metadata service, or local source, and applies it before the operating system starts. This configuration—formatted as JSON—defines partitions, filesystems, files, systemd units, network settings, and user accounts. Once Ignition completes and the machine boots, that window closes; further changes require reprovisioning or layering packages with rpm-ostree.

Operators typically do not write Ignition JSON by hand. Instead, they author a Butane configuration file in YAML, which is then transpiled into Ignition format using the Butane tool (formerly the Fedora CoreOS Config Transpiler, fcct). Butane provides human-friendly syntax and validation, catching errors before deployment. A minimal Butane file might specify SSH keys for the core user and define a systemd service to run a container; the transpiled Ignition config ensures that configuration is applied exactly as declared, with no partial states possible.

Misconfigured Ignition files can render a machine unbootable. Debugging typically involves console access or reading logs from the live environment, and fixes require regenerating the Ignition file and reprovisioning. This discipline enforces infrastructure-as-code rigor, but the workflow feels alien to anyone expecting to SSH in and run dnf install. For production container workloads—especially Kubernetes nodes or orchestrated fleets—the trade-off is worthwhile; for ad-hoc experimentation, it can be punishing.

Automatic updates and the rpm-ostree model

Fedora CoreOS updates itself automatically. By default, Zincati checks for new releases on the selected stream (typically stable), downloads the updated OS image, and schedules a reboot. The update is atomic—either it succeeds completely or rolls back to the previous known-good version. This mechanism relies on rpm-ostree, a hybrid package system that treats the entire OS as a versioned image rather than a collection of individually installed packages. Each update is a new commit in an OSTree repository, and the bootloader can boot into any previous commit if needed.

The bi-weekly release cadence means security patches and bug fixes arrive quickly, but it also demands that operators stay current. Each Fedora CoreOS stream is based on a Fedora Linux release, which receives approximately 13 months of support. Falling behind on updates can leave instances running unsupported versions. The phased rollout strategy—where updates deploy gradually across the fleet via the Cincinnati update service—mitigates the risk of a bad release taking down all machines at once, and teams can run some instances on the testing or next streams to catch issues early.

Traditional package installation is intentionally crippled. If an operator needs additional system-level tools like vim or htop, they must layer them on top of the base image using rpm-ostree install, which requires a reboot. The recommended approach, however, is to run any non-essential software in containers or use toolbox, a utility that launches a Fedora container for interactive debugging. This philosophy keeps the host minimal and consistent, but it also means CoreOS is unsuitable for workloads that expect a mutable, general-purpose Linux environment.

Where CoreOS fits and where it does not

Fedora CoreOS excels in environments where container orchestration is the primary workload and infrastructure is managed as code. Kubernetes clusters benefit enormously from CoreOS nodes—automatic updates, SELinux enforcement, and minimal footprint reduce operational overhead, and the immutable model prevents configuration drift across dozens or hundreds of nodes. OKD and Red Hat OpenShift use variants of CoreOS as their host OS for exactly this reason. The system also shines in CI/CD pipelines, edge computing, and IoT devices where reproducibility and security matter more than flexibility.

It is poorly suited for general-purpose servers, development workstations, or any scenario that requires interactive package installation or frequent system reconfiguration. Traditional web servers, databases, or monolithic applications that expect to install directly on the host will fight against CoreOS's design. The immutable paradigm demands a shift in thinking—from pets to cattle, from configuration to code—and teams without container-native workflows will find the transition painful. Documentation is thorough but assumes familiarity with Kubernetes, Podman, and declarative provisioning; newcomers face a steep on-ramp.

Comparable alternatives include Ubuntu Core (which uses snaps instead of containers and targets IoT), AWS Bottlerocket (Amazon's own container OS optimized for EKS), and openSUSE MicroOS (which uses Btrfs snapshots for transactional updates). CoreOS differentiates itself with strong Red Hat and Fedora community backing, tight Kubernetes integration, and the maturity of rpm-ostree and Ignition. For organizations already invested in the Fedora or Red Hat ecosystem, or running Kubernetes at scale, CoreOS is a natural choice. For everyone else, the question is whether the operational benefits justify the learning curve.