How CoreOS’s automatic update model affects your uptime planning

Every other OS on our list leaves patching entirely up to you: you decide when to run updates, and whether a reboot happens at all. CoreOS inverts that. By default, it checks for updates, downloads them, and reboots to apply them – automatically, without asking. This is the trade-off at the heart of “near-zero maintenance,” and it’s worth understanding exactly how it works before it reboots your production instance at a moment you didn’t choose.

Zincati: the agent doing this

The component responsible for auto-updates is Zincati, which runs as a background service on every CoreOS host. It periodically checks a Fedora-run update service for new releases, downloads a new OS image via rpm-ostree when one’s available, and – depending on configuration – reboots into it.

The default finalisation strategy is called immediate: as soon as an update has finished staging locally, Zincati reboots to apply it. There’s no built-in delay and no maintenance window unless you configure one. On a default install, that means your instance can reboot itself at any time.

The three update streams

Fedora CoreOS releases updates through three streams, and which one your instance tracks affects how fresh – and how tested – the updates you receive are:

• stable – the recommended default for production use; updates have already passed through testing and next
• testing – a preview of what’s about to reach stable, useful for catching problems early if you’re running non-critical infrastructure
• next – the earliest, least-tested stream, tracking upcoming changes; not recommended for anything you care about

Unless you have a specific reason to want early visibility of upcoming changes, stay on stable for anything running a real workload.

Controlling when reboots happen

If the immediate strategy’s “reboot whenever an update lands” behaviour doesn’t suit you, Zincati supports alternative strategies, configured via a small config snippet (which, consistent with everything else on CoreOS, you’d typically deliver through your Ignition config so it’s in place from first boot). The two main alternatives:

• periodic – restricts reboots to maintenance windows you define, by weekday, start time, and duration (in UTC by default, or your chosen time zone). Updates still download and stage outside the window, but the reboot itself waits until the window opens.
• fleet_lock – for clusters of CoreOS machines, this coordinates reboots through a central lock-manager service so nodes take turns rather than all rebooting at once and taking your whole fleet down together.

A periodic strategy config looks roughly like this as a Zincati config fragment:

[updates]
strategy = "periodic"

[[updates.periodic.window]]
days = [ "Sat", "Sun" ]
start_time = "03:00"
length_minutes = 60

That example restricts reboots to a one-hour window starting 03:00 UTC on Saturdays and Sundays – updates still download in the background during the week, but the box only reboots to apply them inside that window.

What this means for your uptime planning

Practically, this comes down to a short checklist before you put anything important on CoreOS:

• Assume your instance will reboot itself on its own schedule unless you’ve explicitly configured otherwise – don’t discover this in production
• If a single unplanned reboot would cause a real outage, configure a periodic maintenance window rather than relying on the immediate default
• If you’re running more than one CoreOS instance behind the same service, look at fleet_lock so they don’t all reboot together
• Because your actual workload runs in containers managed by systemd (see our Podman/Quadlet post), a reboot restarts your containers automatically – the OS update itself isn’t destructive, it’s the brief downtime during the reboot that you need to plan around
• For anything genuinely uptime-sensitive, the real answer is redundancy – run more than one instance behind a load balancer – rather than trying to eliminate reboots entirely, since the automatic update model is core to why CoreOS needs so little manual maintenance in the first place

The automatic update model is a genuine benefit – it’s a large part of why CoreOS needs so little hands-on maintenance compared to a traditional server OS. Just make sure you’ve deliberately chosen your reboot timing rather than leaving it to the immediate default and being surprised by it later.