Open-sourcing our Karpenter provider for Hetzner · Paperclip.inc

Skip to content Sign in Start hiring

Features<br>Approvals You're the board on every decision<br>Costs Spend hits the cap, not the bill<br>Goals Lineage from company to task<br>Routines & heartbeats Work runs without you

Open source<br>Built on open source<br>Paperclip is open source under MIT license. We run Paperclip.inc for you so you can spend your time on shipping, not managing servers.

Start hiring →

Pre-built companies<br>SEO Agency Articles every week, on time<br>B2B SaaS Founder Code, ship, close deals<br>Newsletter Ops Weekly send, never late<br>Indie App Studio Idea to App Store, solo

About<br>What is a Paperclip company?<br>Roles, agents, skills, approvals, and budgets. Ready to hire as a whole. Run a team of five. Stay a team of one.

Browse all companies →

Paperclip.inc<br>Sign in Start hiring

By Paperclip Team · June 16, 2026 · 7 min read

Today we are open-sourcing a Karpenter provider for Hetzner Cloud, under Apache 2.0. It implements Karpenter’s CloudProvider interface against the Hetzner Cloud API, so Karpenter can provision, consolidate, and replace Hetzner servers as Kubernetes nodes, choosing the cheapest server type that fits the pending pods.

We built it for our own infrastructure. Paperclip.inc runs a managed, EU-hosted platform on Kubernetes, with the cluster built on Hetzner and Talos. Those workloads are bursty: the cluster adds capacity when work arrives and gives it back when the work finishes, and each node should be the smallest server that fits. Karpenter does exactly that, but it had no Hetzner provider. The official list covers AWS, Azure, GCP, Cluster API and a handful of others; Hetzner was absent.

Cluster Autoscaler vs Karpenter on Hetzner

Hetzner Kubernetes autoscaling has so far meant the Cluster Autoscaler, usually wired up by kube-hetzner or Cluster API. The Cluster Autoscaler works against fixed node groups: you predefine a pool of one server type, and it adds or removes nodes of exactly that type. To offer a second size you define a second pool, and the scheduler picks between pools rather than picking the right machine for the work.

Karpenter inverts that. It looks at the pods that cannot be scheduled, considers the full catalog of instance types, and launches the single cheapest node that fits them. There are no node groups to size by hand. When a node goes empty or underused, Karpenter consolidates it away. On a provider with as many server types as Hetzner, across shared and dedicated CPU and both x86 and Arm, that selection shows up directly in the bill.

How the provider works

The provider implements Karpenter’s CloudProvider interface against the Hetzner Cloud API:

Cheapest node that fits. It reads Hetzner’s live per-location pricing and offers Karpenter the lowest-cost server type that satisfies the pending pods, across shared (CPX, CX) and dedicated (CCX) CPU.

x86 and Arm. Both architectures are first class, so you can steer workloads onto the cheaper Ampere (CAX) machines wherever your images support arm64.

Talos and Ubuntu. A node joins from a Talos machine config or an Ubuntu cloud-init document, supplied through a Kubernetes Secret so no join credentials ever sit in a manifest.

Drift and consolidation. Empty and underused nodes are removed automatically. A server whose image, network, firewall, server type, location or labels no longer matches its HCloudNodeClass is flagged as drifted and replaced.

One detail worth calling out, because it is the kind of thing that quietly breaks autoscalers: Karpenter garbage-collects nodes by periodically listing the instances the provider manages and deleting any NodeClaim whose server is gone. Our List() is scoped by a karpenter.sh/cluster label, so two clusters sharing a single Hetzner project never see each other’s servers and can never garbage-collect each other’s nodes. Getting that boundary right is the difference between an autoscaler and an outage.

Install

The controller ships as a multi-arch image and an OCI Helm chart, both signed with cosign and published with SLSA provenance and an SBOM.

Terminal windowkubectl create namespace karpenter

kubectl -n karpenter create secret generic hcloud-token \

--from-literal=token="$HCLOUD_TOKEN"

helm install karpenter-provider-hetzner \

oci://ghcr.io/paperclipinc/charts/karpenter-provider-hetzner --version 1.0.0 \

--namespace karpenter \

--set clusterName=my-cluster \

--set auth.secretRef.name=hcloud-token

You also need Karpenter’s own NodePool and NodeClaim CRDs installed, the same as any Karpenter setup.

Define your nodes

An HCloudNodeClass says how to build a node: which network, which image, how to bootstrap it. Here is a Talos worker on a private network, pinned to an exact image by label so you get the precise Talos version and the system extensions you baked in (gVisor, in our case):

apiVersion: karpenter.hetzner.cloud/v1alpha1

kind: HCloudNodeClass

metadata:

name: default

spec:

locations:...