Cluster provisioning
Declarative, repeatable builds: the cluster can be rebuilt from the repository rather than from someone's memory of how it went the first time.
On-prem Kubernetes
Built to last longer than the project that built it.
A production cluster designed around your constraints, handed over with the repository and the runbooks, then kept current, because that's the part that actually decides whether it survives.
Why this is one engagement, not two
The build is the easy part.
Kubernetes ships three minor releases a year, each supported for roughly fourteen months. A cluster nobody actively maintains is running unsupported within about two years of handover, and the team that inherited it usually discovers this in the middle of responding to a CVE.
So upgrades, patching and version currency are part of this engagement rather than an optional follow-on. An engagement that ends at handover has sold you the easy half.
~14
months of upstream support per minor release
Three releases a year. Miss two cycles and you're on an unsupported version with no patch path.
Phase one: build
What gets built.
Scoped to your constraints rather than a reference architecture. You end up with the repository, the runbooks and a handover session, plus people on your side who understand it.
Storage
Persistent volumes on local NVMe, sized and tuned for the workloads you're actually running, with the failure behaviour understood before it happens.
Ingress and certificates
Traffic termination, routing and certificate issuance and renewal, so nothing expires quietly at the weekend.
Identity
Single sign-on wired to your provider, with roles that map to how your team is actually organised.
Delivery
Deployments driven from Git so changes are reviewable, revertible and attributable, rather than applied by hand.
Backup and restore
Backups configured, and (the part usually skipped) restores actually tested, so recovery time is a measured number.
Phase two: run
What keeps happening.
The ongoing half. You keep operating the cluster day to day; we own the work that has a deadline attached to it whether or not anyone notices.
- Control-plane and node upgrades, planned and executed
- Security patching on a defined cadence
- Version currency, so you never fall out of support
- Certificate and credential rotation
- Capacity review as workloads grow
- Incident response against agreed targets
Response targets
Typical, then agreed with you.
These are the targets most engagements settle on. The specifics, and the coverage level behind them, are set in your contract, because what's reasonable depends on what we can reach and how quickly.
| Severity | Response | Cover |
|---|---|---|
| Production cluster down | 1 hour | 24×7 cover |
| Production degraded | 4 hours | 24×7 cover |
| Non-production or planned work | 1 business day | Business days |
| Advisory questions | 2 business days | Business days |
Commercially
A build fee and a term.
Priced as a build phase followed by a term, quoted per engagement, rather than a project price with a retainer bolted on at the end. It's a commitment to the cluster's life instead of its launch, and it means handover isn't the moment someone tries to sell you something.
Tell us what you're building on.
Hardware, constraints, timeline, and what happens to it after. The scoping call is free and ends with a written proposal or an honest no.