<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>K3s on Project Wintermute</title><link>https://wintermutecore.com/tags/k3s/</link><description>Recent content in K3s on Project Wintermute</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 05 Mar 2026 14:00:00 +0200</lastBuildDate><atom:link href="https://wintermutecore.com/tags/k3s/index.xml" rel="self" type="application/rss+xml"/><item><title>k3s on Hetzner: notes from running production clusters</title><link>https://wintermutecore.com/posts/k3s-hetzner-production-notes/</link><pubDate>Thu, 05 Mar 2026 14:00:00 +0200</pubDate><guid>https://wintermutecore.com/posts/k3s-hetzner-production-notes/</guid><description>&lt;p&gt;&lt;strong&gt;TL;DR.&lt;/strong&gt; k3s on Hetzner is a strong cost-control move when you are willing to operate the cluster. Mind the Flannel MTU on Hetzner private networks, separate stateless and stateful workloads at the storage layer, keep observability minimal but real, and treat backups as a tested practice rather than a config setting.&lt;/p&gt;
&lt;p&gt;A managed Kubernetes service is the right answer for most teams. When it is not the right answer (cost, control, locality of data), self-hosted k3s on a low-cost provider like Hetzner is one of the better options. We have run several clusters of this shape in production for over a year. This post is the set of decisions that have held up.&lt;/p&gt;</description></item></channel></rss>