Cloud infrastructure and DevOps
Most infrastructure we are asked to look at was set up once, by hand, by someone who is no longer around, and now nobody wants to touch it. Deploys depend on one laptop. The cloud bill grows every month and nobody can say why. Alerts fire so often they get muted, so the real outage is found by a customer. We write the setup down as code, cut what you pay for and do not use, and make the pager mean something again.
Four ways this arrives.
Resources were created in the console over several years and nobody can say which ones matter. We inventory the account, bring what is live into Terraform, remove what is not, and hand you a repository that describes the whole estate.
It is usually idle capacity, oversized instances, forgotten environments and data transfer nobody priced. We find where the money goes, cut the obvious waste where you already are, and only then ask whether a cheaper provider such as Hetzner suits your steady workloads.
One person knows the steps and every release waits for them. We build a pipeline that tests, builds and deploys on merge, with rollback to the previous image, so shipping on a Friday afternoon is a decision rather than a gamble.
The channel fires all day, so everyone has muted it, so real outages are reported by customers. We alert on what users actually feel, route each alert to a named owner, and delete every alert nobody would act on at 3am.
A K3s cluster on Hetzner that we provisioned and are on call for, deployed through Flux, where only a push to master can produce an image production will run.
Read the write-up →Asked on nearly every call.
Should we run our own Kubernetes cluster?+
Usually not. Self-hosting starts to pay when your managed bill is mostly things you do not use, your workloads are steady rather than spiky, and someone is willing to own the control plane. We run our own on Hetzner, so we know what that job involves. If nobody on your side wants it, managed is cheaper in total even when the invoice is larger.
Do we need Kubernetes at all?+
Often not. Plenty of products are better served by a managed container service, a platform like Railway, or two virtual machines and a good deploy script. Kubernetes earns its place when you run several services, have steady traffic and have people to look after it. We will recommend the least infrastructure that does the job, and say so when that is less than you expected.
Which clouds do you work with?+
AWS most often, then Google Cloud, Azure and Hetzner. We work in whichever one you are already on, because moving clouds is rarely the cheapest fix for a cost or reliability problem. If we think a move is worth it, we will show you the case using your own bill before anyone migrates anything.
Can you cut our cloud bill without a migration?+
Usually, yes. Most of a bill that has grown unchecked is idle capacity, oversized instances, environments left running and data transfer nobody priced, and all of that is fixed where you already are. We will not promise a percentage before we have read the bill. After the first week we can tell you what is realistic and what it takes to get there.
Who is on call?+
Whoever the engagement says, in writing. While we run your infrastructure it can be us, with hours and response times agreed up front. If you are taking it in-house, the handover includes the runbooks, the alert routing and a rota your team can actually staff. We do not leave behind a pager that only we know how to answer.