What is Fedora CoreOS, and who is it actually for?

If you’ve provisioned a Fedora CoreOS VPS expecting it to work like Ubuntu, Debian, or AlmaLinux with a different label on the tin, stop here first. It doesn’t. CoreOS is built on a genuinely different model, and if you approach it the way you’d approach a normal Linux server, you’ll spend your first hour confused about why useradd doesn’t exist and dnf install isn’t the answer to anything.

This post is the orientation stop. We’ll explain what CoreOS actually is, what “immutable” means in practice, and – most importantly – who this OS is genuinely for and who should pick something else from our image list instead.

“CoreOS” today means Fedora CoreOS

Worth clearing up first, because the name has a confusing history. The original CoreOS Container Linux, from the company CoreOS Inc., was a standalone product. Red Hat acquired CoreOS Inc. in 2018, and Container Linux reached end of life in May 2020. Its provisioning model and automatic update philosophy were merged with Red Hat’s Fedora Atomic Host to produce Fedora CoreOS, which is the actively maintained successor. When we say “CoreOS” on this VPS image list, we mean Fedora CoreOS. There’s no separate, standalone CoreOS distribution still in active development.

It’s immutable – the root filesystem is read-only

On a traditional server OS, the root filesystem is just a directory tree you can write to whenever you have permission. On CoreOS, the root filesystem is mounted read-only. You can’t touch a file into /usr, and you can’t casually edit system binaries or libraries, because the OS is designed to actively stop you.

Updates aren’t applied package by package with a tool like apt or dnf. CoreOS uses rpm-ostree, which treats the OS as a single versioned image. An update downloads a complete new OS image, and the whole thing is swapped in atomically on the next boot. There’s no partial-update state where half your packages are new and half are old – you’re either on the previous image or the new one, in full.

This is a deliberate trade-off. You lose the flexibility of hand-editing system files. In exchange you get an OS that’s very hard to get into an inconsistent state, and updates that are trivially reversible by rolling back to the previous image.

There’s no first-boot setup wizard, and no “create a user later”

This is the part that catches people out most. Every other OS on our list gives you some kind of interactive or semi-interactive first-boot flow, and if you get it wrong, you can always SSH in later and fix it with useradd, passwd, or a config file edit.

CoreOS has none of that. It ships with no default login and does essentially nothing on first boot except read a configuration file called an Ignition config and apply it – once. That single pass is when your user accounts, SSH keys, filesystem layout, and systemd units get set up. If you boot a CoreOS instance without supplying one, you’ll get a running machine you effectively cannot log into.

Ignition is not a configuration management tool that keeps running and reconciling state – it’s a provisioning tool that runs early in boot, once, and then gets out of the way. If you want to change your Ignition-managed configuration afterwards, the normal pattern is to update your config and reprovision, not to hand-edit the running system. We cover the practical side of writing an Ignition config in the next post in this series.

It’s built to run containers, not installed services

CoreOS deliberately ships a minimal base – there’s no package manager for adding arbitrary software to the host in the way you’d use apt or dnf on a general-purpose distro. What it does ship is Podman, ready to pull and run OCI containers, plus systemd to supervise them.

The expectation is that your actual workload – your web app, your database, your reverse proxy – runs inside containers, not as software installed directly onto the host. The host’s job is to stay minimal, stay updated, and run your containers reliably. It is not the place to install Nginx from a package repo and configure it by hand.

It updates itself, automatically, on a schedule

By default, CoreOS checks for updates, downloads them, and reboots to apply them – without you doing anything. This is a core part of the design, not an optional extra you’re expected to disable. It’s what “near-zero maintenance” actually buys you: you’re not the one responsible for remembering to patch the OS. We go into the update mechanism, and how to control the timing, in a dedicated post later in this series.

Who CoreOS is genuinely for

• Anyone running containerised workloads (Podman or Docker-style images) who wants the host OS itself to require essentially no ongoing admin
• Teams who provision infrastructure declaratively and are comfortable treating a server as disposable – replace it, don’t patch it by hand
• People running Kubernetes nodes, CI runners, or single-purpose container hosts where the OS is plumbing, not the product
• Anyone who wants automatic OS security updates without building their own patching pipeline

Who should pick a different OS instead

• Anyone wanting to install software with a traditional package manager and manage it directly on the host
• Anyone expecting to create or modify user accounts after boot with commands like useradd or passwd
• Anyone running software that isn’t packaged as a container and can’t easily be containerised
• Anyone who wants full manual control over exactly when the OS updates and reboots, without setting up the additional configuration CoreOS needs to constrain that
• Anyone new to Linux administration who wants a more forgiving, conventional environment to learn on

If that second list sounds like you, one of the other distributions in our VPS image list will suit you better. If the first list sounds like you, the rest of this series covers exactly what you need to know: writing your first Ignition config, running containers with Podman, and living with CoreOS’s automatic update model.