For a fireside chat with creators and maintainers of #SpecialPurposeOS #Linux distributions like #Flatcar or #Kairos at #FOSDEM, please drop by our SPOS BOF Session: Today (Saturday) 5pm in K4.401.

No matter whether you're curious, a user, or a maintainer - drop by and join us!

(Also, please boost!)
https://fosdem.org/2026/schedule/event/GX3DNS-special-purpose_linux_operating_systems_meetup_bof/

🌅 New day, new Flatcar releases!

Alpha 4515.0.0, Beta 4459.1.1, and Stable 4459.2.0 are out with Linux 6.12.54, cgroups v1 kernel config mitigations, and major security updates across the stack.

#Flatcar #Linux #ContainerLinux

I rarely talk about work here, but this took quite some effort of the team and fellow maintainers:

https://pixelrobots.co.uk/2025/11/flatcar-container-linux-on-aks-first-look/

Today, we add #Azure #AKS to our list of hosted #Kubernetes offers that support #Flatcar #Container #Linux. It's not the first, and it sure won't be the last. Documentation is here: https://learn.microsoft.com/en-us/azure/aks/flatcar-container-linux-for-aks

859 contributions to 6 repositories, says my #CNCF Contributor card

And the whole journey started with a contribution to #Flatcar, thanks to @thilo

https://contribcard.cncf.io/jasonbraganza

Spent some time thinking about a #DevOps flow for agency-sized orgs working on web applications.

The idea is using #nix to pack a reproducible dev environment and build a docker image from it, which will be deployed on a container-host OS like #flatcar .

Principles:
- must be usable for small-sized projects on private infra or cloud providers
- must be development-first, so 1:1 parity between a local environment and production and no DevOps gates during deployments
- everything outside the dev env should be minimally intrusive
- OSS and lightweight sw is preferred

Locally we would have a nix-shell with runtime, toolchain (dependency managers and such) and a webserver. Also obv the app's git repo.
Then we would have a *build node* that acts as a docker registry and an online dev env. A simple pipeline would:
- pull the git repo
- build the docker image with nix
- push it to the local docker registry
- run the image and serve it.
This is automatable in a number of ways, including Ansible straight from the dev's machine without external CI tools.

The *prod node* would leverage Flatcar's init system to pull the latest the docker image and run it at boot, the provisioning can be done manually or via Terraform.

All testing (including security) runs in the dev environment.
Environment variables are also managed inside the application (with something like dotenvx) with appropriate secret management, keeping in mind that every build is a prod build, and all else is dev.

Database and observability systems are to be considered external dedicated services. Static assets (like media files) on the prod node are stored in a volume keeping the same paths as dev's.
Basic status-based orchestration can be done in docker leveraging healthchecks.