Who owns the Kubernetes and GPU side at your company today?
Someone specific, or whoever notices first. Fifteen engineering teams run on stacks we maintain: patched monthly, about a hundred upstream charts tracked for CVEs, Terraform, CI. Their engineers never touch it and we never take the pager.
In shortDixence is a small Swiss engineering team that runs the monthly Kubernetes and GPU maintenance for teams without a platform engineer. Driver, GPU Operator and Container Toolkit are pinned and tested together, chart upgrades run in a validated order, and the changelog and runbook land in your repositories. Fixed monthly fee, and we never take the pager. Fifteen engineering teams run on stacks we maintain.
For fifteen engineering teams the answer is a small Swiss team that runs the scheduled work and never takes the pager. The numbers first.
The Tuesday night you already know
The driver pin
Someone bumps a training image to CUDA 13.3. Your nodes are pinned to R580 or R595, which cap CUDA at 13.2. The job fails on the driver, not on the code.
The chart nobody owns
ingress-nginx is retired. It still serves traffic, and no security fix is coming. Picking a Gateway API implementation is on nobody's list.
The upgrade nobody wants to run
GPU Operator 26.7.0 needs containerd 2.0. The CNI goes last and alone. Nobody wrote down the order, so nobody wants to be the one who runs it.
From the September matrix
- Run Kubernetes 1.35 or 1.36. 1.37 is out since 2026-08-26 but the GPU Operator, cert-manager, Cilium, Calico, Helm 4.2 and ingress-nginx don't support it yet.
- Pin the driver to R580 LTS or R595 production. That caps CUDA at 13.2; CUDA 13.3 needs a driver branch NVIDIA gives no support length.
- ingress-nginx is retired. No build tested on Kubernetes 1.36 will ever exist. Pick a Gateway API implementation.
- GPU Operator 26.7.0 needs containerd 2.0. Upgrade containerd first, then the operator.
- Container Toolkit below 1.17.8 carries two published CVEs, one Critical.
Read the full matrix, checked line by line against the official pages
What we do every month
- Pin and test the driver, operator and container toolkit versions together before they reach your nodes.
- Run the chart upgrades in the validated order: cert-manager and ingress first, the CNI last and alone.
- Write the changelog: the CVEs that mattered this month, and the ones that didn't.
- Hand you the runbook, in your repos and your cloud accounts. Nothing lives on our side.
Seven hours ahead of you
We're in Switzerland. Maintenance runs while your team sleeps and is done before you log on. During your day we're reachable until the end of the East Coast afternoon.
| In-house | Dixence | |
|---|---|---|
| Upgrade order | Whoever remembers | Written, tested monthly |
| Maintenance window | Your working day | Your night |
| Pager | Yours | Yours |
| Runbook, Terraform, state | Wherever they ended up | Your repos, your cloud accounts |
| Cost | A hire, three to six months out | Fixed monthly fee |
Two ways to start, lightest first
Send the output of kubectl version and your GPU Operator version, redacted however you like. You get back what's behind, what breaks first if nobody touches it, and what we'd change first. About forty minutes on our side, nothing on yours.
One written page about your cluster
Or the matrix, every month: leave your email and the October edition arrives when the upstream pages change. One email a month, nothing else.
The matrix, every month
The October edition arrives when the upstream pages change: driver branch, GPU Operator, CUDA ceiling, cert-manager, ingress. One email a month, nothing else.
Questions we get asked
Do you take the on-call pager?
No. We run the scheduled work: monthly upgrades, patching, the runbook. Your team keeps on-call, and nothing depends on us in the middle of your night.
Which Kubernetes version should we run with GPUs in September 2026?
1.35 or 1.36. 1.37 is out since 2026-08-26 but the GPU Operator, cert-manager, Cilium, Calico, Helm 4.2 and ingress-nginx don't support it yet.
Where do the runbook, Terraform and state files live?
In your repositories and your cloud accounts. Nothing lives on our side: if we ever went quiet you'd have the repos, the state files and the runbooks the same morning.
How do we start?
Send the output of kubectl version and your GPU Operator version, redacted however you like. You get back one written page: what's behind, what breaks first if nobody touches it, and what we'd change first. About forty minutes on our side, nothing on yours.
Who we are
A small Swiss team, engineers only. Fixed monthly fee. Everything stays in your repositories and your cloud accounts, so if we ever went quiet you'd have the repos, the state files and the runbooks the same morning.