The Show HN comments asked the same question four different ways: why this over the existing immutable distros? This is the page that should answer it — honest, side-by-side, with no overclaiming. Use it, fork it, keep what's true.
Boot a USB ISO, run Docker. No YAML, no Ignition, no talosctl. The OS gets out of the way.
Atomic rpm-ostree updates, Ignition-only first boot. Built for replicated cloud workloads.
API-driven, no SSH. Talos exists to run Kubernetes clusters and nothing else.
The CoreOS-fork-with-a-vendor. Like Fedora CoreOS, but maintained by Microsoft via Kinvolk.
The marketing copy on every immutable-Linux site sounds the same — "minimal", "secure", "atomic updates". The honest differences are downstream of one decision: what scale are you running this at, and how much config language are you willing to learn before first boot?
| Dimension | Lightwhale | Fedora CoreOS | Talos Linux | Flatcar |
|---|---|---|---|---|
| First-boot config | none Boot & go. Optional setup-wifi, setup-hostname. |
Ignition JSON file required at first boot. | machine config YAML +talosctl apply-config. |
Ignition / CL config |
| Container runtime | Docker Engine | Podman (rootless-friendly) | containerd (k8s-managed only) | Docker / containerd |
| Kubernetes assumption | none just runs containers | optional works either way | required the OS is the k8s node | optional |
| Update model | Swap immutable image, reboot. Manual. | Automatic rpm-ostree with rollback. |
Dual-disk image swap with rollback, API-triggered. | Automatic OTA channels. |
| SSH access | yes | yes | no API-only by design | yes |
| Hardware | x86-64 only. no Pi, no Apple silicon | x86-64, ARM64, s390x, ppc64le | x86-64, ARM64 (incl. Pi 4/5) | x86-64, ARM64 |
| Install | Write ISO to USB, live-boot. Persistence opt-in via magic file lightwhale-please-format-me. |
PXE / cloud image / coreos-installer. | PXE / metal-amd64 ISO / cloud images. | Same as CoreOS lineage. |
| Maintainer | Solo (Stephan Henningsen, Asklandd) | Fedora CoreOS WG (Red Hat) | Sidero Labs (commercial) | Microsoft (Kinvolk) |
| "Hello, Docker" time-to-first-container |
~5 min from USB write to docker run |
~30–90 min (write Ignition, boot, configure) | ~45–120 min (config, talosctl, bootstrap k8s) | ~30–90 min (similar to FCOS) |
Honesty serves Lightwhale better than overclaiming. The cohorts below are the ones for which each project is genuinely the best fit. Telling someone "go use Talos, you'll be happier" when they're spinning up a 50-node cluster is how trust gets built.
You want one or two boxes in your house running Plex, Home Assistant, Immich, Nextcloud, a torrent box, a game server. You don't want to spend a weekend learning a config language. You'd rather docker run than write Ignition JSON.
You want zero attack surface, no SSH, full API-driven node lifecycle. You're operating tens to thousands of k8s nodes and you want declarative rollbacks. The learning curve is the price of admission.
talosctl or are willing to learn it.You want automatic OTA updates and atomic rollbacks. You're deploying containerized workloads on cloud or bare metal at fleet scale. You don't need k8s but you do need a vendor backing the update channel.
If you're running one Docker container on a Raspberry Pi for a friend's website, the immutability premium isn't free — it costs configuration ergonomics. Plain Ubuntu/Debian + apt install docker-compose is still a great answer for a lot of cases.
/etc is a graveyard of half-applied tutorials. Lightwhale's /etc resets every reboot unless you tell it not to.Three concerns came up in the Show HN thread. Pretending they didn't would make this page worse than useless. Here's the straight read.
True, and that backing means production rigor, larger CVE response teams, and a maintenance contract you can buy. Lightwhale doesn't compete on that axis.
It competes on the axis those projects don't serve well: the home user who wants to run Docker without becoming a part-time SRE. That's a real cohort, it just isn't the one Red Hat or Sidero Labs build for.
The first-day burden is similar. The 24-month burden isn't.
On Ubuntu, every fix you ever apply, every config tweak, every PPA you add, every "I'll just try this" lives in your root filesystem permanently. Lightwhale flips the default: persistence is opt-in. A reboot is a free reset.
The Show HN clarified the active source is at bitbucket.org/asklandd/lightwhale, not the GitHub mirror.
This page should link there directly so anyone who lands here doesn't repeat the confusion. (If you ship this page, point the "source" CTA at Bitbucket and mark the GitHub mirror as legacy.)
Stephan said in the thread: "Lightwhale is already running in production. I'm only announcing it for home servers because that's where most people are willing to try it out."
That sentence belongs on the homepage. Right now a visitor has to read HN to learn it.