Flatcar Container Linux Overview

By Kokil Thapa | Last reviewed: September 2026

You need a host OS that stays out of the way. A Flatcar Container Linux overview starts there: a minimal, read-only Linux built to run containers, not to accumulate packages and config drift. After Red Hat absorbed CoreOS Container Linux, the community fork became Flatcar. Teams still choose it when they want predictable nodes, automatic updates, and almost nothing installed on the metal beyond systemd, containerd, and your workloads. If you run Linux system administration for production clusters, this page maps what Flatcar is, how it updates, and where it fits next to Talos, Ubuntu, and plain cloud images.

What is Flatcar Container Linux and how does it differ from traditional Linux?

Flatcar Container Linux is a minimal operating system for running containers at scale. The project maintains the spirit of CoreOS Container Linux: no apt, no yum, and no casual SSH edits to system files. You treat the host as cattle, not a pet.

Traditional distros like Ubuntu Server encourage package installs, manual tuning, and long-lived snowflake configs. Flatcar inverts that model. The OS image is a single unit. You change behavior through Ignition at first boot, systemd units, and containers—not by editing files under /etc and hoping they survive the next update.

In practice, that shift reduces surprise after reboots. I've seen production Laravel and API stacks run fine on Flatcar nodes when the app lives entirely in containers and the host stays boring. The same pattern works for booking platforms deployed on container orchestration where uptime and repeatable deploys matter more than GUI tools on the server.

Core design principles

• Immutable base: Root and /usr mount read-only. Writable state lives on separate partitions or tmpfs.
• Automatic updates: Omaha-style streaming updates replace the whole OS image with rollback support.
• Container-first: containerd is the default runtime; Docker can be enabled as a systemd service when needed.
• Declarative provisioning: Ignition configures disks, users, networks, and units on first boot.
• Minimal attack surface: Few packages, no compiler toolchain on the host, fewer paths for supply-chain creep.

Partition layout you should expect

Flatcar ships with an A/B partition scheme for the OS. One slot is active; updates write to the inactive slot. After reboot, the bootloader switches. If the new image fails health checks, you roll back to the previous slot.

Typical layouts also include:

1. EFI or BIOS boot partition — holds bootloader metadata.
2. Two OS partitions — A and B images for atomic swaps.
3. Stateful partition — often mounted at /var for container layers, logs, and persistent data.
4. Optional OEM or custom partitions — cloud images may add config drives for Ignition.

Do not store application databases directly on the OS partition. Mount persistent volumes or use a separate data disk. That rule matches how I design nodes for automated database backups on Linux elsewhere: data lives outside the replaceable OS.

How does Flatcar Container Linux handle updates and immutability?

Immutability is the headline feature in any Flatcar Container Linux overview. The root filesystem mounts read-only. update_engine and update_service pull signed payloads from Flatcar release channels. Reboot applies the swap.

You pick a channel when you install:

• Stable — production default; tested releases.
• Beta — newer builds for staging clusters.
• Alpha — bleeding edge; avoid on revenue paths.
• LTS — extended support window for teams that cannot reboot often.

Updates are whole-image replacements, not incremental package patches. That sounds heavy. In return you get a known filesystem hash per release and fewer "works on my node" drifts across a fleet.

Update flow in production

Configure a maintenance window. Flatcar can reboot automatically after download, or you can gate reboots with locksmithd when running clustered software. For Kubernetes, cordon and drain the node before the OS reboot. Uncordon after kubelet rejoins.

Check current version and channel:

flatcar-update -s
cat /etc/flatcar/update.conf
grep FLATCAR_RELEASE_VERSION /etc/flatcar-release

Lock to a specific version during a sensitive migration:

sudo systemctl stop update-engine
echo 'REBOOT_STRATEGY=off' | sudo tee -a /etc/flatcar/update.conf

Re-enable updates only after validation. I've encountered teams that disabled updates during a payment-gateway cutover and forgot to turn them back on. Schedule a calendar reminder. Stale nodes become your weakest link.

What stays writable

/etc is a symlink into /usr/share/oem or stateful storage depending on image type. Runtime state goes to /var. Custom systemd units belong in /etc/systemd/system on the stateful partition. Treat those files as code: version them in Git and bake them through Ignition or cloud-init-compatible providers—not manual vim sessions.

For security hardening, pair immutability with signed container images and regular scans. The host is smaller, but your images still need discipline.

How do you provision and deploy Flatcar Container Linux in production?

First boot is where Flatcar earns its keep. Ignition reads a JSON or YAML config from metadata (cloud), a config drive, or an ISO embed. It partitions disks, creates users, writes files, and enables systemd units before your SSH key ever connects.

Minimal Ignition snippet that sets a hostname and creates a user:

{
  "ignition": { "version": "3.4.0" },
  "storage": {
    "files": [{
      "path": "/etc/hostname",
      "contents": { "source": "data:,worker-01" }
    }]
  },
  "passwd": {
    "users": [{
      "name": "core",
      "sshAuthorizedKeys": ["ssh-ed25519 AAAA...your-key"]
    }]
  }
}

Validate before deploy using the official transpiler or online validator linked from Flatcar documentation. Bad Ignition bricks first boot. You debug through serial console or IPMI, which is slow at 2 a.m.

Common deployment paths

1. Cloud images — AWS, GCP, Azure, and others publish Flatcar AMIs and images. Pass Ignition via user-data.
2. ISO + PXE — bare metal and KVM lab clusters boot the installer image, then pivot to disk.
3. Omni or Terraform — infrastructure-as-code pipelines render Ignition and attach it to instance metadata.
4. Kubernetes bootstrap — kubeadm, k3s, or a managed distribution installs after the node Ignition completes.

After boot, join the node to your fleet tooling. Flatcar ships with toolbox or debug containers for host inspection—use them instead of installing debug packages on the host. That workflow aligns with debugging a running container rather than polluting the OS.

Running systemd services and containers together

Systemd manages both OS services and container lifecycles. A typical unit for Docker (if enabled) looks like:

[Unit]
Description=My App Container
After=network-online.target docker.service
Requires=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker run --rm --name myapp -p 8080:8080 ghcr.io/org/myapp:1.2.3
ExecStop=/usr/bin/docker stop myapp

[Install]
WantedBy=multi-user.target

Prefer containerd and nerdctl or a kubelet-managed pod when you can. Docker on Flatcar is optional and adds a daemon you must patch through OS updates. For greenfield clusters, follow the Container Runtime Interface path and keep Docker off the node.

Need ad-hoc JSON validation on the host? Run a throwaway tool container instead of installing jq locally. The same pattern applies to the JSON formatter in your browser—keep utilities out of the base image.

Flatcar Container Linux vs Talos Linux vs Ubuntu: which should you choose?

Teams ask this during every platform refresh. Flatcar is a general-purpose container host with familiar systemd semantics. Talos Linux is Kubernetes-only and API-driven. Ubuntu is a full distro you configure yourself.

Verdict: choose Flatcar when you want immutability and auto-updates but still need systemd units for edge cases—reverse proxies, legacy agents, or single-node container stacks without Kubernetes. Choose Talos when every node is K8s and you accept API-only ops. Stay on Ubuntu when the team relies on apt, complex multi-service VMs, or mixed PHP-FPM and database on one box.

On shared EC2 fleets I maintain with Deployer and GitLab CI, Ubuntu still wins for symlinked PHP releases. For a dedicated monitoring or CI runner farm, Flatcar is often cleaner. Match the OS to the workload shape, not the hype cycle.

What are common production pitfalls when running Flatcar Container Linux?

Flatcar removes some problems and introduces others. Most failures I see are operational, not kernel bugs.

Stateful data in the wrong place

Containers disappear; volumes must not. Bind-mount critical data to the stateful partition or network storage. After an OS update reboot, ephemeral paths under tmpfs vanish. Document mount paths in runbooks.

Disabled updates and channel skew

Pinning versions during incidents is valid. Leaving nodes pinned for months is not. Automate compliance checks that alert when FLATCAR_RELEASE_VERSION diverges across the fleet.

Debugging without a package manager

Install nothing with curl-to-bash on the host. Use toolbox or run a debug container with --pid=host --net=host when you need tcpdump or strace. See systemd service management for unit-level troubleshooting.

Resource limits ignored

Flatcar does not magically cap containers. Apply CPU and memory limits in Kubernetes or systemd. The guide on limiting Docker container resources applies to nerdctl and Docker alike.

Security and supply chain

Run sandboxed runtimes for untrusted workloads. Pull from a private registry such as Harbor. Scan images on every build. Immutable hosts help, but a bad image still runs.

Observability and performance tuning

Export node metrics with node_exporter as a container. Ship logs off-node early. Flatcar's minimal surface means fewer OS metrics to watch, but disk pressure on /var still kills nodes silently. Review Linux performance tuning basics for sysctl and disk I/O patterns that apply inside the stateful partition.

For enterprise platforms that mix custom APIs and orchestration, pair Flatcar nodes with solid CI and registry hygiene. That is the same discipline I apply on enterprise application development engagements: automate the boring parts, document the rest.

Key Takeaways

• Flatcar Container Linux is an immutable, container-first host OS with A/B updates and Ignition-based provisioning.
• Keep application data on stateful or network volumes; never treat the OS partition as persistent storage.
• Use containerd and systemd units by default; enable Docker only when your stack truly requires it.
• Pick Flatcar over Ubuntu when you want auto-updates and fleet consistency; pick Talos for Kubernetes-only API-driven ops.
• Version Ignition configs in Git, validate before boot, and monitor release channel drift across nodes.
• Debug through toolbox or privileged debug containers—do not install packages on the host.

People Also Ask

Is Flatcar Container Linux still maintained after CoreOS?

Yes. The Flatcar project continues as the community successor to CoreOS Container Linux. Releases, security patches, and documentation live at flatcar.org. Microsoft acquired Kinvolk, the primary maintainer, but the OS remains open source under the same operational model.

Can you run Flatcar without Kubernetes?

Absolutely. Flatcar works well for single-purpose servers that run one or more containers under systemd. Kubernetes is common, not required. CI runners, observability stacks, and edge proxies are typical non-K8s uses.

Does Flatcar include Docker by default?

Recent images emphasize containerd. Docker is available but often disabled until you enable the systemd unit. For new deployments, standardize on containerd to reduce daemon overhead and align with the Kubernetes CRI.

How do Flatcar updates compare to apt upgrade on Ubuntu?

Flatcar replaces the entire OS image from a signed channel. Ubuntu applies incremental package updates. Flatcar gives you all-or-nothing consistency per version; Ubuntu gives flexibility at the cost of per-node package drift.

Build your container platform on solid infrastructure

This Flatcar Container Linux overview should leave you with a clear picture: immutable hosts, declarative first boot, streaming updates, and containers doing the real work. The OS stays small so your team spends time on applications, not patching libc on production metal. If you are planning a migration from generic VMs to container-native nodes—or need help hardening an existing fleet—support and maintenance and hands-on Linux experience can shorten the path. Contact us to talk through your stack, or browse the blog for deeper guides on runtimes, registries, and deployment patterns.