Ignition applies disk and user configuration before the root filesystem

Disk work happens in the initramfs

Ignition is described as a utility for manipulating disks during the initramfs, and that placement explains almost everything about how it behaves. The set of jobs it performs is concrete: partitioning disks, formatting partitions, writing files such as regular files and systemd units, and configuring users. On first boot it reads its configuration from a source of truth, and the listed possibilities are a remote URL, a network metadata service or a hypervisor bridge, which means the same image can be configured differently depending on where it is being launched. The important design point is the timing. Nothing is baked into the image, so the image stays immutable and identical across a fleet, and the divergence between machines lives in configuration rather than in artifacts. The flip side is that the configuration is the whole system state, so a mistake in it is not a partial failure, it is a machine that comes up wrong or not at all.

Ignition JSON or Butane YAML, with translation at boot

Ignition accepts two config formats, and the relationship between them is worth being precise about. The native format is Ignition JSON, documented in the specs file in the docs directory. The second is Butane YAML, documented in the butane directory, and when a Butane config is provided, Ignition transpiles it automatically at boot. That transpilation is a feature of the boot-time path, not a separate binary you have to run. Separately, this repository also contains Butane as a standalone transpiler, and the butane command line tool has two jobs of its own: local config validation, and features such as --files-dir that require client-side processing because they need to read local files before the machine exists. So there are two places the translation can happen, at build time on your laptop or at boot time on the target, and the tool exists so that the same YAML can be checked locally before it is ever shipped.

Validating a config before it reaches a machine

The cheapest failure in an Ignition deployment is a malformed config that only shows up after a machine has already booted and failed to partition anything. The project gives you two ways to catch that early. There is a command line tool called ignition-validate, with binaries for it on the releases page, and there is a container image, quay.io/coreos/ignition-validate, which lets you validate a config in CI without installing anything. The documented invocation pipes a config file into the container on standard input:

# This example uses podman, but docker can be used too
podman run --pull=always --rm -i quay.io/coreos/ignition-validate:release - < myconfig.ign

The read from standard input is the detail that makes this fit a pipeline. A configuration file can be validated exactly as it will be delivered, with no volume mounts and no working directory assumptions, and the container is pulled with --pull=always so that validation is not silently testing an old image. For a team using Butane, the local butane binary covers the same ground before the YAML is converted, and it can also resolve the client-side features that a pure validator would not touch.

A dracut module and a systemd unit are how it ships

Ignition does not install itself like a normal application, and the Makefile shows how it is meant to land. The install target copies the dracut modules into a dracut modules.d directory under the destination root, then makes the shell scripts and generators in those modules executable. It installs ignition into a dracut module directory named 30ignition, which is the stage that runs during initramfs, and it installs the ignition-validate binary into the system bin directory for the validating case. Two symlinks are created under libexec, one named ignition-apply and one named ignition-rmcfg, both pointing at the same binary, so the initramfs can invoke the same program under different names depending on the stage. A systemd unit named ignition-delete-config.service is installed into the systemd system directory, and the name says exactly what it does: once the config has been applied, the copy that was consumed is deleted from the machine, which is the mechanism that stops a stale configuration from being reapplied on the next boot.

Building the binaries with the local build script

The build is driven by a small set of make targets over a ./build script, and the default target produces the whole set of artifacts. That target covers ignition itself, ignition-validate, a cross compiled ignition-validate, butane and a cross compiled butane, and each has its own target that calls the build script with the binary name. The cross compiled variants exist for distributions that need to ship validation binaries for platforms other than the build host, and the Makefile comments say this is used in Fedora for now. The architecture handling is the other half of the build story. The Makefile maps the host machine architecture from uname -m onto the Go names, covering x86_64 to amd64, aarch64 to arm64, loongarch64 to loong64, the arm variants to arm and the 32 bit x86 case to 386, then exports it. The module itself is a modern Go module, declaring module path github.com/coreos/ignition/v2 and a Go language version of 1.25.0.

Who actually runs it, and what it is not for

The usage note in the README is blunt and useful. You probably do not want to invoke Ignition directly, and in fact it is not even present in the root filesystem, since it lives in the initramfs and runs once. The interesting list is the set of known users, which tells you the platforms that have adopted this model: Fedora CoreOS, Red Hat Enterprise Linux CoreOS, Flatcar, openSUSE MicroOS and SUSE Linux Enterprise Micro. That is a useful filter for an evaluation, because all of them share the same constraint of an immutable, centrally configured operating system image. The dependency list shows how much of the platform surface Ignition reaches, with cloud provider metadata and object storage clients for the major clouds, Azure identity, the AWS SDK, the go-systemd bindings, a YAML parser and the VMware guestinfo library for hypervisor configuration. The project is Apache-2.0 licensed, publishes regular releases with v2.28.0 dated 2026-10-15, and its last push was on 2026-10-19.

Editorial conclusion

Ignition fits a platform team building an immutable operating system image where the machine has to configure itself the first time it boots, because it separates the desired state from the image, supports a range of remote config sources, and gives you a validator and a YAML front end before either reaches production. It does not fit a normal Linux host that a person administers by hand, since the tool is not even present in the root filesystem and is meant to be driven by a platform, and it does not fit a team that wants a hosted configuration service, because fetching the config is the platform's job. Before you adopt it, pin a release, since v2.28.0 is dated 2026-10-15 and the last push was on 2026-10-19, run your Butane or Ignition config through quay.io/coreos/ignition-validate in CI, and confirm the config source is reachable in the environment you are provisioning, since that source of truth is the only thing standing between a machine and a blank disk.

Frequently asked questions

Official sources

1. coreos/ignition on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases