Flatcar and Fedora CoreOS Release History: Channels, Updates, Support

Flatcar Container Linux and Fedora CoreOS are the two community successors to CoreOS Container Linux, which reached end of life on 26 May 2020. Both are minimal, image based Linux hosts for containers that update themselves automatically, keep the operating system read only, roll back a bad update, and are configured once at first boot by Ignition. Flatcar ships Alpha, Beta, Stable and LTS channels; Fedora CoreOS ships next, testing and stable streams.

Flatcar is a direct fork that kept Container Linux's build, A/B partitions and update client; Fedora CoreOS merged the Container Linux model with Fedora Atomic Host's rpm-ostree. This post goes one level deeper than our Fedora, CentOS Stream and RHEL pipeline explainer and sits next to our Alpine Linux release history and ChromeOS channels post, since Flatcar's disk layout was inspired by ChromeOS.

Key takeaways

• Red Hat agreed to acquire CoreOS on 30 January 2018, and Container Linux reached end of life on 26 May 2020.
• Kinvolk announced Flatcar on 6 March 2018. The CNCF accepted it on 2 August 2024 at the Incubating level.
• Fedora CoreOS previewed on 24 July 2019 and reached general availability on 17 January 2020, replacing Container Linux and Fedora Atomic Host.
• Flatcar channels promote Alpha to Beta to Stable. Any Stable major version is supported until the next Stable major ships. Each LTS major is maintained for 18 months, with a new LTS roughly once a year and a 6 month overlap.
• Fedora CoreOS streams promote next and testing toward stable. The design document targets two weeks between releases, machines always move to the newest release on their stream, and there is no long term support stream.
• Flatcar writes each update as a full image to the passive USR partition, verifies it against a baked in public key whose private half sits on an air gapped hardware security module, and checks /usr at every boot with dm-verity.
• Fedora CoreOS uses Zincati and a Cincinnati update graph to pick the next release and rpm-ostree to stage it. Update barriers make old machines learn new signing keys before jumping ahead.
• Ignition runs once, in the initramfs, on first boot, from a Butane YAML file converted to JSON. Treat that file like a credential.
• Flatcar publishes an SPDX 2.3 SBOM and package lists for every release. Fedora CoreOS is built from Fedora RPMs and also ships as an OCI image.

A dated timeline

Dates are checked against the primary sources listed below; current versions were read on 24 October 2026.

What was CoreOS Container Linux, and how did the two successors continue it?

CoreOS, Inc. was founded in 2013, according to Red Hat's acquisition press release, and its first product was an operating system that did very little on purpose. Container Linux shipped a kernel, systemd, a container runtime, SSH and not much else. There was no package manager on the host. You did not install software on a Container Linux machine; you ran it in containers. The operating system itself arrived as a whole image, updated itself in the background onto a second partition, and rebooted into the new version when a reboot manager said it was safe.

Both successors kept four ideas from that model: the OS is one versioned image with identical bits in /usr; updates are staged in the background and applied atomically by a reboot, with the old version kept for rollback; a machine is configured once at first boot by Ignition, which CoreOS created; and release channels let a few machines run the newest build so most can run one that has already been exercised.

Red Hat announced its agreement to buy CoreOS on 30 January 2018. The CoreOS end of life page says the open source components carried on in Red Hat's products and community projects, and that on 26 May 2020 Container Linux "reached its end of life and will no longer receive updates." Flatcar's February 2020 blog adds that from 1 September that year the published Container Linux resources would be deleted or made read only.

Flatcar: a fork that kept the build

Kinvolk's 6 March 2018 announcement explains why it forked rather than simply offering support: commercially supporting a distribution, it argued, needs full control over building, signing and delivering the images and updates. So Kinvolk rebuilt Container Linux independently, which explains most of Flatcar today:

• The build is still the Gentoo derived SDK, with ebuilds in the flatcar/scripts repository.
• The disk layout is the nine partition GPT scheme with two OS partitions, USR-A and USR-B, borrowed from ChromeOS.
• The update client is update_engine, speaking the Omaha protocol to Nebraska, the update server Kinvolk open sourced in November 2019.
• The channel names and version numbering came straight across, so Flatcar could act as a drop in replacement in 2020.

By February 2020 Flatcar had made almost 200 releases and re-introduced ARM support, according to its blog, and after the end of life it continued "completely independent of upstream CoreOS." Its website footer now describes the project as a Series of LF Projects.

Fedora CoreOS: a merger rather than a fork

Fedora went the other way. The July 2019 preview announcement described Fedora CoreOS as the successor to both Fedora Atomic Host and Container Linux, combining Container Linux's provisioning tools and automatic update model with Atomic Host's packaging technology, OCI support and SELinux security. In practice:

• It is built from Fedora RPMs, and its version starts with the Fedora major it is based on.
• The OS is delivered as OSTree commits managed by rpm-ostree, not partition images.
• Ignition carried over as the provisioning tool.
• The update agent is new: Zincati, which asks a Cincinnati update graph server what to update to and tells rpm-ostree to do it.

The preview post said Container Linux would be maintained until about six months after Fedora CoreOS was declared stable, and Atomic Host until the end of life of Fedora 29. Fedora CoreOS was declared ready on 17 January 2020 and Container Linux ended about four months later. The general availability post was blunt: "Container Linux machines cannot be migrated in place to Fedora CoreOS."

The Fedora CoreOS FAQ describes it as the upstream basis for RHEL CoreOS, which is released and life cycled with OpenShift. It also says the goal is to eventually build Fedora CoreOS on top of Fedora bootc, a newer effort for bootable containers.

How do Flatcar channels work, and how long is each supported?

Flatcar has four public channels. The switching channels documentation describes how a release moves through them.

Stable never receives a brand new major; it gets the bug fix release of a major that already passed through Alpha and Beta. The docs recommend running Stable with a few nodes on Beta to validate workloads.

Flatcar's version.txt files carry FLATCAR_BUILD, FLATCAR_BRANCH and FLATCAR_PATCH. On 24 October 2026 they read 4820.0.1 for Alpha, 4820.1.0 for Beta, 4757.2.2 for Stable and 4081.3.11 for LTS, so the middle number was 0, 1, 2 and 3 respectively. That is an observation, not a documented contract; read the channel from /usr/share/flatcar/update.conf instead of parsing versions.

LTS in more detail

Flatcar opened LTS to the community on 10 May 2022. Each LTS is based on an LTS upstream kernel and gets critical and security fixes but no new features or major component updates. The 2022 announcement put new LTS majors roughly 12 to 15 months apart, against "a typical two-month refresh cadence for Flatcar Stable," with 18 months of maintenance and a 3 to 6 month transition window. The current docs say a new LTS roughly once a year, 18 months of support and a 6 month overlap.

GROUP=lts follows whichever LTS stream is current, so your machines take a major jump when the project moves it. GROUP=lts-2024 (or another year) freezes a machine on one stream, which the docs recommend so you can move each year on your own schedule.

Past streams include LTS-2021 (major 2605), LTS-2022 (major 3033) and LTS-2024 (major 4081), and the releases page also has a feed for LTS 2023. Check one point yourself: the releases page notice on cgroups v1 says LTS-2024 "will receive regular updates until early 2026, and hit EOL in mid-2026," yet on 24 October 2026 the LTS channel still pointed at 4081.3.11, released 23 October 2026, and no LTS-2025 or LTS-2026 stream was listed. Read the current release notes before you plan a migration date.

How do Fedora CoreOS streams work, and how long is each supported?

Fedora CoreOS has three production streams, described in the update streams documentation and the project's design document.

Version strings follow X.Y.Z.A, per the FAQ: X is the Fedora major, Y is the date the package set was snapshotted, Z is 1 for next, 2 for testing and 3 for stable, and A is a rebuild counter. So 44.20260928.3.2 is the second stable build of Fedora 44 content snapshotted on 28 September 2026. The FAQ warns the scheme is not meant to be parsed by machines.

The design document says stream cadences "are not contractual, but will initially have two weeks between releases." Because stable is a promoted testing build, its packages can be up to four weeks old, so urgent security fixes go out in out of cycle releases.

Support works differently from Flatcar. A machine follows a stream, Zincati keeps it on the newest release, and the stream itself rebases onto each new Fedora major, next first, then testing, then stable. There is no Fedora CoreOS equivalent of Flatcar LTS; the slower, contract backed lifecycle on the same technology is RHEL CoreOS, tied to OpenShift. The update streams page strongly encourages running a share of each fleet on testing and next to catch breaking changes early, much as Flatcar asks for Beta nodes.

How do A/B partitions, read only /usr and automatic updates work?

Flatcar: two USR partitions, update_engine and Nebraska

The Flatcar disk partitions guide lists nine GPT partitions. The ones that matter here:

Each USR partition carries three GPT attributes, priority, tries and successful. Per the learning series and rollback guide:

1. update_engine checks the update server and writes the next release, as a full partition image, to the passive USR partition. The supply chain page says Flatcar never updates individual binaries or packages.
2. Before installing, update_engine validates the payload with a public key built into the OS partition. Only a validated update is installed.
3. update_engine gives the passive partition a higher priority and one try (tries=1), then reports UPDATE_STATUS_UPDATED_NEED_REBOOT.
4. A reboot manager decides when to reboot: by default locksmithd, whose reboot strategy waits 5 minutes, while etcd-lock takes a distributed lock first and off never reboots. On Kubernetes the docs recommend the Flatcar Linux Update Operator; kured is supported after release 3067.0.0.
5. GRUB boots the highest priority partition and decrements its tries counter. If the new version keeps running for "around two minutes," update_engine marks it successful.
6. If the new version never gets marked successful, GRUB falls back to the other partition on the next boot. That is the automatic rollback.

Integrity does not rely on the read only mount alone. A dm-verity hash of the OS partition is computed at build time and stored in the initrd, and /usr is verified on each boot, so a modified block fails verification.

The default update server, public.update.flatcar-linux.net, runs Nebraska. Your own Nebraska instance can mirror the public channels (-enable-syncer), hold back a version by pointing a group at your own channel, and serve payloads to offline machines (-host-flatcar-packages). The public server does not offer downgrades, so a machine moved to a lower versioned channel waits until that channel catches up unless you use flatcar-update.

Fedora CoreOS: OSTree deployments, rpm-ostree and Zincati

Fedora CoreOS gets atomic updates and rollbacks from OSTree deployments instead of partitions, using two components:

• rpm-ostree keeps multiple OSTree deployments on disk and chooses between them at boot.
• Zincati checks for updates and applies them through rpm-ostree.

Zincati polls a Cincinnati server, which serves an update graph rather than a simple "latest" pointer. That graph supports two safety features:

• Phased rollouts. The server offers a release to a growing share of clients. Nodes may send a rollout_wariness hint from 0.0 (eager) to 1.0 (cautious); the docs suggest a few canaries near 0.0 and say normal workers "should not have zero wariness."
• Update barriers and dead ends. Some releases must be passed through, and some are marked as dead ends that must be left.

A reboot finalizes a staged update. Zincati's default immediate strategy reboots at once; fleet_lock first asks a lock manager for a slot over the FleetLock HTTP protocol; periodic reboots only inside weekly UTC maintenance windows.

Rollback is manual for a running system: the previous deployment stays on disk, you can pick it at the boot menu for a one off boot, or run rpm-ostree rollback -r to make it the default and reboot. Zincati keeps upgrading to any newer release, so disable it if you need to stay on the older one while you investigate. Note also that the update streams page now switches streams by rebasing onto a signed container image, ostree-image-signed:docker://quay.io/fedora/fedora-coreos:<stream>; Fedora CoreOS ships as an OCI image as well as disk images.

How are update payloads signed?

The Fedora CoreOS barrier page gives a worked example: Fedora 32 based images first trusted keys for Fedora 31 to 33; release 32.20200907.3.0 added the Fedora 34 key and became a barrier, so older machines had to pass through it before taking Fedora 34 based releases. Rebasing between streams can skip barriers, one documented route to regressions.

Flatcar's supply chain page adds build provenance. Flatcar builds from source, generates per package SLSA provenance for most packages, ships it in the image under /usr/share/SLSA/, and assesses itself at SLSA Level 3. It also lists gaps: builds are not yet hermetic, there is no TPM based chain of trust yet, and build system changes do not need a second administrator. Signature checks on images you download yourself are "not enforced by the distribution"; flatcar-install does check them.

How is a machine provisioned with Ignition, and why does that matter for security?

Ignition, inherited from CoreOS, is described in its documentation as "a utility created to manipulate disks during the initramfs": it partitions disks, formats filesystems, writes files and systemd units, and creates users before the real root filesystem is mounted. Its rationale page states the rule plainly: "Ignition runs only on the first boot."

Ignition reads JSON with a fixed schema, versioned by spec (the docs list config specs 3.0.0 through 3.7.0). Humans write Butane YAML and convert it. The Fedora CoreOS FAQ explains that Butane adds distribution specific helpers Ignition lacks, so conversion is more than a YAML to JSON translation, and separate formats stop the wrong file reaching the wrong tool. Butane has variants: fcos for Fedora CoreOS and flatcar for Flatcar. The Butane specs page lists stable fcos specs up to 1.7.0 and flatcar specs 1.0.0 and 1.1.0; the Flatcar Butane guide uses variant: flatcar with version: 1.0.0.

Ignition reads its config from the platform: cloud user data, a hypervisor channel such as QEMU's fw_cfg, or a remote URL. Current Ignition docs say it can also transpile Butane itself, but converting ahead of time with --strict catches mistakes before boot.

Why first boot only matters for security:

• No drift. The machine is exactly what the config said, so the config is the one thing to review and version control.
• Mistakes persist until reprovisioning. A wrong SSH key or an over broad sudo rule is not fixed by editing the Butane file later.
• The config often carries secrets. Password hashes, SSH keys, cluster join tokens and TLS material end up in cloud user data, which processes on the instance can often read through the metadata service. Fetch secrets at runtime where you can and restrict metadata access.
• Remote configs need integrity. When Ignition fetches a config from a URL, use HTTPS and the spec's verification hash so a tampered file is rejected.
• It runs with full power. A unit written by Ignition can run anything as root on every boot, before your other tooling starts. Review Butane changes like production code.

When did Flatcar join the CNCF, and how are security advisories published?

The CNCF project page says Flatcar was accepted on 2 August 2024 at the Incubating maturity level, the middle tier between sandbox and graduated, which the CNCF describes as "used successfully in production by a small number users." Fedora CoreOS is a Fedora edition, not a CNCF project.

Flatcar's security page asks reporters to email the project with affected versions and a reproducer, prefixing urgent reports with [URGENT], and publishes the image signing key. Fixes are announced in release notes, where each release lists its security fixes by component with CVE identifiers. The releases page offers ATOM and JSON feeds per channel and per LTS year, which is the practical way to watch for them.

Fedora CoreOS takes its packages from Fedora, so fixes arrive in the next testing and stable builds, or in an out of cycle release when urgent. The FAQ lists a coreos-status mailing list for operational notices, where the launch post promised announcements of major breakage with mitigations. We found no separate Fedora CoreOS advisory format beyond release notes and that list.

What is in each OS image, and how do you get an SBOM or package list?

Both images are small by design: a kernel, systemd, a container runtime, Ignition, the update stack, SSH and basic tools. Here is what the Flatcar releases page listed on 24 October 2026:

Fedora CoreOS launched in January 2020 with Linux 5.4, systemd 243, Ignition 2.1, Podman 1.7 and Moby 18.09; today stable tracks Fedora 44 and next tracks Fedora 45.

Extensions differ too. Flatcar announced in December 2023 that it was replacing torcx with systemd-sysext, so optional components arrive as system extension images rather than packages. Fedora CoreOS supports OS extensions by layering RPMs with rpm-ostree, and its FAQ suggests building on Fedora bootc instead if you need heavy customization.

What Flatcar publishes per release

The release directory for each version and architecture includes, beside the disk images:

• flatcar_production_image_sbom.json: an SPDX 2.3 SBOM. The Stable 4757.2.2 file we downloaded was about 16 MB, created on 21 October 2026, and listed 1,413 packages, generated by an open source SBOM tool scanning the root filesystem including sysext packages.
• _packages.txt (package list), _contents.txt (every file), _licenses.json and _kernel_config.txt, each prefixed flatcar_production_image.
• flatcar_production_image_verity.txt (the dm-verity hash) and a _pcr_policy.zip archive whose use we did not find documented.

Images carry .DIGESTS, .DIGESTS.sig and .DIGESTS.asc files; the smaller text artifacts carry .sig files directly. Per package SLSA provenance is inside the image at /usr/share/SLSA/.

What Fedora CoreOS gives you

We found no published SPDX or CycloneDX SBOM in the Fedora CoreOS docs we reviewed. You do have:

• The OS is made of RPMs, so on a node rpm -qa lists them and rpm-ostree status shows which deployment is booted and which is staged.
• rpm-ostree db diff shows package changes between deployments, worth reading before you reboot after a rebase.
• Fedora CoreOS is published as an OCI image at quay.io/fedora/fedora-coreos:<stream>, so image tooling that understands RPM databases can inventory it without booting a machine.

Comparison: Flatcar, Fedora CoreOS and a general purpose distribution

Both container hosts trade hand tuning for a uniform, updated, recoverable fleet. A general purpose distribution gives more freedom and longer release support, and leaves drift and patching to you.

Which one should you pick?

Step by step: Butane to Ignition, boot a VM, pin a channel and check rollback

The walkthrough uses QEMU on a Linux workstation with KVM. Run the Flatcar and Fedora CoreOS parts separately; each takes about ten minutes.

1. Write a Butane config

Create flatcar.bu for Flatcar. Replace the key with your own public key.

variant: flatcar
version: 1.0.0
passwd:
  users:
    - name: core
      ssh_authorized_keys:
        - ssh-ed25519 AAAA...your-public-key... you@example
storage:
  files:
    - path: /etc/flatcar/update.conf
      overwrite: true
      mode: 0644
      contents:
        inline: |
          GROUP=stable
          REBOOT_STRATEGY=reboot
          LOCKSMITHD_REBOOT_WINDOW_START="Sun 04:00"
          LOCKSMITHD_REBOOT_WINDOW_LENGTH=1h

And fcos.bu for Fedora CoreOS. The Butane specs page lists fcos versions up to 1.7.0; 1.6.0 is used here, and you can move to the newest spec your target release supports.

variant: fcos
version: 1.6.0
passwd:
  users:
    - name: core
      ssh_authorized_keys:
        - ssh-ed25519 AAAA...your-public-key... you@example
storage:
  files:
    - path: /etc/zincati/config.d/51-rollout-wariness.toml
      mode: 0644
      contents:
        inline: |
          [identity]
          rollout_wariness = 0.5
    - path: /etc/zincati/config.d/55-updates-strategy.toml
      mode: 0644
      contents:
        inline: |
          [updates]
          strategy = "periodic"
          [[updates.periodic.window]]
          days = [ "Sat", "Sun" ]
          start_time = "22:30"
          length_minutes = 60

2. Convert Butane to Ignition

Use the Butane container so you do not need a local install. --strict fails on warnings, and --pretty makes the output readable for review.

docker run --rm -i quay.io/coreos/butane:release --pretty --strict < flatcar.bu > flatcar.ign
docker run --rm -i quay.io/coreos/butane:release --pretty --strict < fcos.bu > fcos.ign

# Review what will actually run at first boot
jq '.storage.files[].path, .passwd.users[].name' flatcar.ign fcos.ign

Keep the .bu files in version control and generate the .ign files in CI so nobody hand edits JSON.

3. Download and verify a Flatcar image, then boot it

First import the Flatcar image signing key from the project's security page and check its fingerprint against the one published there. Then download the QEMU wrapper, the image and their signatures, and verify both.

CH=stable
BASE=https://$CH.release.flatcar-linux.net/amd64-usr/current
curl -fLO $BASE/flatcar_production_qemu.sh
curl -fLO $BASE/flatcar_production_qemu.sh.sig
curl -fLO $BASE/flatcar_production_qemu_image.img
curl -fLO $BASE/flatcar_production_qemu_image.img.sig
gpg --verify flatcar_production_qemu.sh.sig
gpg --verify flatcar_production_qemu_image.img.sig
chmod +x flatcar_production_qemu.sh

# Pass the Ignition config; SSH is forwarded to localhost:2222
./flatcar_production_qemu.sh -i flatcar.ign -- -nographic

Only continue if gpg prints "Good signature" from the Flatcar buildbot key. From a second terminal:

ssh -p 2222 core@localhost

4. Download and boot a Fedora CoreOS image

coreos-installer download fetches the image for a stream and verifies its signature.

STREAM=stable
mkdir -p ~/fcos && cd ~/fcos
coreos-installer download -s $STREAM -p qemu -f qcow2.xz --decompress -C .
IMAGE=$(ls fedora-coreos-*-qemu.x86_64.qcow2)

qemu-img create -f qcow2 -F qcow2 -b "$IMAGE" my-fcos-vm.qcow2
qemu-kvm -m 2048 -cpu host -nographic \
  -drive if=virtio,file=my-fcos-vm.qcow2 \
  -fw_cfg name=opt/com.coreos/config,file=$PWD/fcos.ign \
  -nic user,model=virtio,hostfwd=tcp::2223-:22

Then ssh -p 2223 core@localhost. On hosts with SELinux enabled, the Fedora CoreOS QEMU page says the image and Ignition file must be labeled svirt_home_t, for example by keeping them under ~/.local/share/libvirt/images/.

5. Check which version and channel or stream you are on

On Flatcar:

cat /usr/share/flatcar/os-release          # version of the running OS
cat /usr/share/flatcar/update.conf         # channel baked into the image
cat /etc/flatcar/update.conf               # your overrides from Ignition
update_engine_client -status               # current update state
journalctl -u update-engine -e             # update attempts and errors

On Fedora CoreOS:

rpm-ostree status                          # booted and staged deployments
grep -E 'OSTREE_VERSION|VERSION_ID' /etc/os-release
systemctl status zincati.service           # agent, strategy, current release
journalctl -u zincati -e                   # update decisions over time

rpm-ostree status marks the booted deployment and lists any staged one waiting for a reboot. The Zincati log shows its Cincinnati server, its strategy and which target release it selected.

6. Pin a channel or stream

To move a Flatcar machine to another channel, set the group in /etc/flatcar/update.conf. To freeze on one LTS year instead of following lts, name the year.

sudo sed -i 's/^GROUP=.*/GROUP=beta/' /etc/flatcar/update.conf
# or, to stay on one LTS stream: GROUP=lts-2024
grep GROUP /etc/flatcar/update.conf
update_engine_client -check_for_update

The machine "should check for an update within an hour," per the docs. Moving from Beta back to Stable waits until Stable passes your version, because the public server does not downgrade, unless you use flatcar-update --to-version.

On Fedora CoreOS, switching streams is a rebase. The docs suggest backing up /var first and switching toward newer content (stable to testing to next) rather than back, because upstream software usually migrates data forward, not backward.

sudo systemctl stop zincati.service
sudo rpm-ostree rebase "ostree-image-signed:docker://quay.io/fedora/fedora-coreos:testing"
rpm-ostree db diff                         # inspect package changes
sudo systemctl reboot

7. Check rollback state

On Flatcar, read the USR partition attributes. The boot disk is /dev/vda in this QEMU example; confirm yours with lsblk and rootdev -s /usr before you look.

lsblk
rootdev -s /usr                            # which USR partition is mounted
sudo cgpt show /dev/vda | grep -A3 'USR-'

The active partition has the higher priority and successful=1. After an update is staged, the other partition shows a higher priority with tries=1; after a good boot and about two minutes, it becomes successful=1. If it never does, GRUB returns to the old partition.

On Fedora CoreOS, a rollback to the previous deployment is one command:

sudo systemctl stop zincati.service
sudo rpm-ostree rollback -r                # make the previous deployment default and reboot
# later, to rejoin the stream:
sudo systemctl enable --now zincati.service

Practise this in the lab first: a service whose data was migrated by a newer version may not read it after a rollback.

Where Safeguard fits, honestly

Safeguard does not manage these hosts: it does not run update servers, schedule reboots, verify OS image signatures or scan firmware. The fit is the software on top and the inventory the projects publish. Flatcar's SPDX SBOM can be scanned like any SBOM file with safeguard scan --sbom flatcar_production_image_sbom.json, putting the host package inventory beside your application inventory. Containers you run on either OS can be scanned with safeguard scan --image <name> and repositories with safeguard scan --dir ., matched against vulnerability databases, ranked by reachability and checked by your policies and gates. Kernel and base OS fixes still come from Flatcar and Fedora through their channels.

Common mistakes

• Treating Stable as set and forget. A Stable major is supported only until the next one, so a node with updates disabled is unsupported within months. On LTS, pin GROUP=lts-<year> and plan the yearly move.
• Disabling Zincati or update-engine to stop reboots. That also stops security updates. Use reboot strategies, maintenance windows or a lock manager instead.
• Running every node on stable or Stable. Both projects ask you to run some nodes on testing or Beta. Without canaries, the first sign of a regression is your production fleet.
• Rebasing Fedora CoreOS backward between streams. Going from next to stable can skip update barriers and run software older than the data it last wrote.
• Editing a provisioned machine by hand. /usr is read only, and hand edits in /etc drift from your config. Change the Butane file and reprovision.
• Skipping image signature checks on manual downloads. Flatcar's docs say validation is not enforced when you download images yourself. Use gpg --verify or coreos-installer download, which verifies for you.
• Forgetting the host in the inventory. Teams often have an SBOM for every container and none for the OS that runs them. Flatcar publishes one; for Fedora CoreOS, export the RPM list.
• Assuming automatic rollback on Fedora CoreOS. Flatcar rolls back automatically when a new partition is never marked successful. Fedora CoreOS keeps the previous deployment, but returning to it is manual unless you add your own health check tooling.

FAQ

Is CoreOS Container Linux still supported?

No. It reached end of life on 26 May 2020 and its published resources were deleted or made read only from 1 September 2020. Replace remaining machines with Flatcar or Fedora CoreOS.

Can I migrate a Container Linux machine to Fedora CoreOS in place?

No. The Fedora CoreOS launch post says in place migration is not possible: write a new Butane config and provision new machines. Flatcar was built as a drop in replacement, so moving to it was the smaller change in 2020.

How long is Flatcar LTS supported?

Each LTS major gets 18 months of maintenance, a new one appears roughly yearly, and they overlap by about 6 months. Check the releases page before planning: its LTS-2024 end date note and its current releases did not line up on 24 October 2026.

Does Fedora CoreOS have a long term support stream?

No. Each machine follows the newest release on next, testing or stable, including each move to a new Fedora major. Longer, vendor backed lifecycles on the same technology come with RHEL CoreOS in OpenShift.

How often do Flatcar and Fedora CoreOS release?

Flatcar's 2022 LTS post described Stable refreshing about every two months, with more frequent Alpha and Beta releases and roughly monthly LTS patch releases. The Fedora CoreOS design document targets two weeks between releases on each stream, with out of cycle releases for urgent fixes. Neither cadence is a contract.

How do I stop automatic reboots without stopping updates?

On Flatcar, set REBOOT_STRATEGY to etcd-lock or off, add a reboot window, or use the update operator on Kubernetes. On Fedora CoreOS, use Zincati's periodic or fleet_lock strategy.

How do I get an SBOM for Flatcar or Fedora CoreOS?

Flatcar publishes flatcar_production_image_sbom.json (SPDX 2.3) with each release. For Fedora CoreOS, run rpm -qa on a node or inventory the OCI image quay.io/fedora/fedora-coreos:<stream>.

How are Flatcar updates verified?

update_engine checks each update payload against a public key built into the read only OS partition before installing it. The matching private key is held on a hardware security module in an air gapped environment. At every boot, dm-verity checks the /usr partition against a hash stored in the initrd.

Fix it without waiting for upstream

Container hosts like these keep the operating system small, but the workloads on them are not small: every container image and service you deploy pulls in open source dependencies that the OS update channel never touches. When a dependency in those images needs a fix, the steps below apply, while host kernel and package fixes keep coming from Flatcar and Fedora CoreOS.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session. Safeguard is installed, safeguard opens the interactive terminal, and you ask it to "fix the lodash CVE in this repo." It reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to services you ship as containers to a Flatcar or Fedora CoreOS fleet.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. A build host that already downloads Flatcar release artifacts is a natural place to scan those SBOMs and your images.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. For a platform team, that means an assistant can work with your Safeguard data only through the tools you allow.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• CoreOS, Container Linux end of life notice
• Red Hat, Red Hat to Acquire CoreOS (30 January 2018)
• Flatcar blog, Announcing the Flatcar Linux project (6 March 2018)
• Flatcar blog, Kinvolk update service and Nebraska project (7 November 2019)
• Flatcar blog, Flatcar enters new era after CoreOS end of life announcement (24 February 2020)
• Flatcar blog, LTS channel and advanced features now available to community (10 May 2022)
• Flatcar blog, torcx deprecation for systemd-sysext (18 December 2023)
• Flatcar, Releases
• Flatcar Stable release directory (current)
• Flatcar docs, Switching release channels
• Flatcar docs, Update and reboot strategies
• Flatcar docs, Supply chain security mechanisms
• Flatcar docs, Disk partitions
• Flatcar docs, Immutable OS, boot process, in-place updates and rollback
• Flatcar docs, Manual rollbacks
• Flatcar docs, Running Flatcar on QEMU
• Flatcar docs, Butane getting started
• Flatcar, Security
• Nebraska update server README
• CNCF, Flatcar Container Linux project page
• Fedora Magazine, Introducing Fedora CoreOS (24 July 2019)
• Fedora Magazine, Fedora CoreOS out of preview (17 January 2020)
• Fedora CoreOS docs, Update streams
• Fedora CoreOS docs, Auto-updates and manual rollbacks
• Fedora CoreOS docs, Signing keys and update barriers
• Fedora CoreOS docs, FAQ
• Fedora CoreOS docs, Producing an Ignition config
• Fedora CoreOS docs, Provisioning on QEMU
• Fedora CoreOS design document (fedora-coreos-tracker)
• Fedora CoreOS stream metadata, stable
• Ignition documentation
• Ignition rationale
• Butane documentation
• Zincati, Auto-updates
• Zincati, Updates strategy

Last reviewed: 24 October 2026.