TalosCon 2025 Amsterdam: Talos, KubeVirt and Dairy Farms

On 16 and 17 October 2025 I was at TalosCon 2025, the yearly user conference for Talos Linux and Omni, hosted by Sidero Labs. It took place at Venue Collective – The Conference on Generaal Vetterstraat in Amsterdam (archived event page). The format was simple: Thursday afternoon for a shared meetup and the welcome reception, and Friday for the keynotes and breakout sessions.

The TalosCon conference badge has already appeared in my conference badges year in review. This post covers the talks themselves, written up from the slides I photographed.

Thursday afternoon: the plenary room set up and still empty, a day before the keynotes.

Thursday: the welcome reception

The event page listed a Portainer workshop and a meetup shared with Cloud Native Amsterdam on Thursday afternoon, then a welcome reception hosted by Sidero from 17:00. The welcome wall at registration read “Welcome to TalosCon 2025” and showed the sponsors: Portainer, TrueFullstaq, Oxide, Isovalent and Kumorion. STACKIT and Isovalent banners stood in the lounge, and by early evening the lounge was full.

Friday keynotes: “How difficult it is to be simple”

Friday opened at 09:00 with a “Welcome to TalosCon” slide. The first keynote was built around two quotes. A slide titled “Manage Configuration Drift…” quoted Peter Drucker: “There is nothing so useless as doing efficiently that which should not be done at all.” The next one, “Or Eliminate Configuration Drift Entirely”, quoted Vincent van Gogh: “How difficult it is to be simple!”

That pairing is the case for Talos in two slides. You can get very good at managing drift on mutable servers, or you can build an operating system that leaves nothing to drift.

The plenary room full for Friday’s opening keynote.

A “You’re in good company” slide listed some of the organisations in the room: i3D.net, Roche, SNCF, Sensys Gatso Group, promptly, Lely, JYSK, Zircuit, embark and CrossnoKaye.

Since last TalosCon

The roadmap slide, “Since last TalosCon”, split the year into two lists.

Talos

• Image cache for faster deployments
• Reengineered user volumes, enabling encryption, raw volumes, swap and more
• Removed GRUB from UEFI systems for stronger security
• SELinux support
• SBOMs for Linux, userspace and extensions
• FIPS-compliant builds

Omni

• Machine join token and other security improvements
• SOC 2 Type II compliance
• Infrastructure providers
• EU-based data center

“Since last TalosCon”: a year of Talos and Omni changes on one slide.

Several items on that list point the same way: security and supply chain (no GRUB on UEFI, SELinux, SBOMs, FIPS builds, SOC 2) plus data residency (an EU-based Omni data center). The current Talos page still describes it as “the immutable, API-driven operating system purpose-built for Kubernetes. No SSH, no shell, no package manager”, and Omni as the place for “provisioning, upgrades, config, and backups for every Talos cluster”, available as SaaS or self-hosted.

A customer slide followed: “Hathora wins on bare metal and hybrid”. According to the slide, Hathora onboarded more than 100 game studios in six months and found that a cloud-only model came with unsustainable costs. The quote on the slide said the team had “about 6 engineers on a team of 11 in total” serving 14 regions, and credited the unified management of Talos Linux and Omni.

Left: “Rebellious systems”, with Talos next to Unix, C, RISC and NoSQL. Right: the title slide of the TrueFullstaq keynote.

Rebellious systems

The next keynote’s slides had an Oxide footer and the tone of a personal story. One slide, “Aside: In retrospect”, showed a September 2018 blog post called “Falling in love with Rust”, which opened with an apology for being “a technology love story”. The slide I kept was “Rebellious systems”. It argued that the size of modern software makes technologists ask “does it have to be this complicated?!”, and that this produces systems that overthrow what came before them, “often by discarding unnecessary constraints”. The examples were Unix (v. Multics), C (v. PL/I), RISC (v. CISC), Rails (v. J2EE), PDF (v. PostScript), microservices (v. monoliths), Node (v. Python/Ruby), NoSQL (v. SQL), and Talos (v. Ubuntu/Rocky).

Then came “Talos Linux is Much More Important Than You Think”, credited on the title slide to Gerrit Tamboer, Chief Evangelist at TrueFullstaq, the company behind the Dutch EDGECASE Kubernetes event.

Roche: “Home is Where the Cache is”

Roche presented its edge platform in the second room. Its agenda ran from the starting point through the challenge, the solution and a demo.

The starting point slide described “A Modern, Connected Edge Platform”:

• Secure foundation: built on Talos OS
• Workflow: standard GitOps
• Assumption: continuous connectivity
• Architecture: centralised management and artifact delivery

The diagram showed an edge template feeding a cluster GitOps repository (with FoxOps in between), and each cluster pulling from that repository.

Roche’s starting point: Talos as the base, GitOps as the workflow, and an assumption of continuous connectivity.

The weak point is that assumption. The slide that answered it was titled “Home is Where the Cache is: Ensuring artifact availability with a local registry”. A local zot registry, running as a Talos system extension, acted as a containerd mirror for the node. Flux’s source-controller and kustomize-controller reconciled from an OCIRepository, and a central Harbor instance for fleet management synced to the edge on demand.

A local zot registry as a Talos system extension, mirroring images for containerd at the edge site.

SGX Group: VM migration with KubeVirt

In the main room, an SGX Group slide summed up their virtualisation move in one line: “KubeVirt gave us a way to treat VMs like any other workload — no exceptions, no handholding, just GitOps.” KubeVirt describes itself as “building a virtualization API for Kubernetes”, and the slide showed what that looks like in practice.

Migration workflow, as listed on the slide:

1. Export the VM definition from RHV or VMware (OVF/OVA).
2. Convert the image to QCOW2 and import it into an internal image registry.
3. Create a KubeVirt VirtualMachine manifest (labels, StorageClass, network).
4. Deploy through Git: Flux reconciles it into the cluster.
5. Validate network and storage performance parity, then decommission the old VM.

Benefits: a full GitOps lifecycle for VMs with no click-based provisioning, backups and replication through standard Kubernetes tools (Velero, VolumeSnapshots), unified monitoring through VictoriaMetrics for VMs and containers, and a path to containerisation later. The “bridging the gap” bullet was the honest one: KubeVirt suits apps that couldn’t yet be containerised, such as legacy services and stateful workloads.

SGX Group’s KubeVirt migration path: export, convert to QCOW2, write the manifest, let Flux deploy it.

Cloud Native Dairy Farming

The most unusual use case of the day was “CNDF: Cloud Native Dairy Farming”. Its premise slide, “The cow as center point”, was a collage of barns, cows, red robotic equipment and a farm dashboard on screens. The Lely logo appeared later on the maintenance portal mock-up.

CNDF: a Kubernetes platform where the cow, not the cluster, is at the centre.

The architecture had gone through several versions. The “Third iteration” slide showed a single Talos Linux VM running KubeVirt, a Horizon backend, support tools and observability, plus a Windows VM on KubeVirt hosting another Horizon backend component. It is the same pattern as SGX Group’s: keep the Windows workload, but run it under Kubernetes.

The “Integration Challenge” slide connected the business side (a customer system and a licensing system feeding a BI integration) with the delivery side (Argo CD deploying Helm charts from an OCI repository, plus a “create cluster template → apply template” step). The answer was a “Metadata Control Plane”: customer data and application data become an application manifest for Argo CD on the customer device, while cluster templates go through Omni.

Left: the metadata control plane feeding Omni and Argo CD. Right: one predictable URL per farm for remote support.

Two more slides covered running it in the field. “Handling HTTP/UDP/TCP” showed the Traefik logo next to other proxy and gateway logos. “Remote support” listed “remote support using exposed services” and a “predictable URL to enable SSO”, with a maintenance portal mock-up offering tiles for Desktop, Dashboards (Grafana), Lely DB, Robots and “Moovefiles” (SCP, VNC and SSH), plus a “Farm name should come here” placeholder.

My take: immutable Kubernetes OS at the edge

Three points from the day are worth carrying into any edge or platform project.

Immutability matters most where nobody is on site. In a data centre a mutable node is an annoyance. On a farm or in a lab, with no administrator nearby, it becomes an outage that someone has to travel to fix. An API-only OS with no shell and no package manager removes a whole class of “someone changed something” incidents. The same argument applies to image-based Linux in general, which I covered in immutable Linux with bootc. If you want to try it, my Talos Linux installation guide is a starting point.

Design the edge for disconnection, not connectivity. Roche’s “Assumption: continuous connectivity” box deserves attention, because many edge designs make that assumption without writing it down. A local registry mirror is cheap insurance. GitOps (Flux or Argo CD, see my comparison) then only has to reconcile what is already cached on site.

VMs on Kubernetes are a migration tool, not a destination. Both SGX Group and the dairy platform used KubeVirt to bring Windows or legacy VMs under the same GitOps lifecycle as containers. The same approach underpins VMware migrations to OpenShift Virtualization, which is also built on KubeVirt. One platform team and one observability stack can serve both kinds of workload while the containerisation work continues.

Related

• How to Install Kubernetes on Talos Linux
• EDGECASE 2026: Gotta Catch ‘Em All
• Operationalizing OpenShift Virtualization at Red Hat
• Immutable Linux with bootc: Atomic Updates and Rollback