Kubernetes, run like production.
We run production Kubernetes and k3s clusters as a managed service: monitoring, backups, upgrades, certificates, GitOps and incident response. Your developers ship the product, and TechOneOps keeps the platform healthy. Running on Hetzner keeps the infrastructure bill low, and we also work with the cluster you already have.
Cluster monitoring, including checks from outside the cluster
Self-managed clusters with multiple control-plane nodes
Cluster configuration versioned in Git and reviewable
A cheap cluster is only cheap while it runs.
Self-managed Kubernetes on Hetzner Cloud is fast, affordable and fully under your control. It also means nobody else is watching the control plane, the volumes or the backups.
In most startups and technical teams, the cluster was built by one or two engineers who now have other priorities. Upgrades get postponed, alerts are tuned once and forgotten, and nobody has tested whether a backup can actually be restored.
TechOneOps takes over that operational layer. You keep the cost advantage of Hetzner and gain a team that knows how the cluster is built, monitors it 24/7 and responds to incidents within the hours of your support plan.
Tools we work with
We have run production k3s on Hetzner Cloud with multiple control-plane nodes, built and operated as code. A typical stack includes tools such as these. If yours differs, we work with what you have.
Cluster
k3s on Hetzner Cloud with a highly available control plane, separate worker pools and floating IPs or load balancers where needed.
Infrastructure as code
Terraform for servers, networks and firewalls, Packer for reproducible node images. A rebuild follows the code, not someone's memory.
Deployment and GitOps
Helm charts, ArgoCD reconciling the cluster from Git, and CI pipelines such as GitHub Actions for build and release.
Storage and backup
Longhorn for persistent volumes, Velero for cluster and volume backups, with copies stored off the cluster, for example in object storage.
Traffic and certificates
Ingress, cert-manager for automatic TLS renewal, and DNS and edge protection through providers such as Cloudflare.
Observability
Prometheus for metrics, Loki for logs, Grafana for dashboards and alerting, Sentry for application errors.
What we watch
Clusters rarely fail all at once. They drift. These are the areas we check regularly, and we add others where your setup needs it.
| Area | What we check | Why it matters |
|---|---|---|
| Observability as code | Dashboards, alert rules and scrape configuration are versioned in Git, not edited by hand | Monitoring survives a rebuild and changes are traceable |
| Metric collection | All targets are scraped, no silent gaps after upgrades or new deployments | An alert that never fires is worse than no alert |
| Storage | Correct storage classes, volume sizes, replica health and free capacity | Full or degraded volumes are a common cause of outages |
| Backups | Velero schedules complete consistently, copies are stored off the cluster, a selected backup is test-restored every month | A backup only counts once it has been restored |
| Alerting from outside | Endpoints and the cluster itself are also monitored from outside the cluster | If the cluster goes down, its own monitoring goes with it |
| Hetzner console inventory | Servers, disks, snapshots, floating IPs and load balancers compared with what the code describes | Forgotten resources cost money and hide risk |
| Images and dependencies | Container images and dependencies scanned for known vulnerabilities, base images kept current | Most exposure comes from outdated components |
| Secrets and access | How secrets are stored and rotated, who has cluster access, which service accounts exist | Access that nobody reviews tends to grow |
Every month in writing
Each month you receive a report with the date, who performed the checks, and technical evidence for each one. Every check is compared with the baseline from the audit, so changes and new deviations are visible at a glance.
Monthly cluster check
| Check | Done | Note |
|---|---|---|
| k3s and node OS updates | Yes | Snapshot taken before the update, versions recorded before and after, nodes drained one at a time |
| Velero backups and test restore | Yes | All scheduled backups complete, selected namespace restored into a test namespace and verified |
| Certificates | Yes | All certificates managed by cert-manager, none expiring within 30 days |
| Hetzner console inventory | Yes | Two unattached volumes found, listed for your approval before removal |
| Image scanning | Yes | One base image with a known vulnerability, update proposed as a separate item |
The example is illustrative. Work beyond the agreed scope is listed separately in the report and approved by you in advance.
How to start
Three steps, each useful on its own.
Cluster audit
In the first two weeks we receive access and a knowledge handover from your team, review your infrastructure code, Helm charts and GitOps repositories, verify the live cluster and set up monitoring and alerting. You receive prioritised findings.
Monthly care
From week three we run the cluster: preventive checks, upgrades, backup restore tests and log review every month, with a written report compared against the audit baseline.
SLA
Business hours (Mon–Fri, 9:00–17:00 CET/CEST) or 24/7 support, with cluster monitoring 24/7 in both. Standard: incident response within 4 hours, service restored within 8 hours, faster by agreement. An uptime commitment is agreed once we know the cluster from the audit.
Clear lines between platform and product
We run the platform. Your developers own the application. Where the two meet, we work together.
- Included in support: on-call readiness, 24/7 monitoring, diagnosis, escalation, restoring service and a written root-cause analysis after each incident.
- We coordinate directly with your developers when an incident involves the application, a deployment or a configuration change.
- Development, performance optimisation and migrations are quoted and approved in advance. Urgent work on an ongoing incident is the exception.
- Requests and questions get a response within one business day. Planned maintenance is announced at least 24 hours ahead, usually outside business hours.
- No lock-in. Everything lives in your Git repositories, and on exit we hand over documentation, configurations, scripts and access.
Questions about Kubernetes operations.
Do you only work with k3s on Hetzner?
No. k3s on Hetzner Cloud is where we have the deepest experience, but we also work with other Kubernetes distributions, dedicated servers and other providers. The audit shows what your cluster needs.
Do we have to change our tools?
No. The stack above is an example. We work with your existing CI, deployment and monitoring tools and suggest changes only where they reduce real risk or effort.
Can you move us from a managed Kubernetes service to Hetzner?
Yes. We plan the target cluster, build it as code, run it in parallel with your current environment and switch over in an agreed window. Migrations are quoted separately before work starts.
Who handles an incident caused by our application?
We detect it, diagnose it and restore service where it can be done on the platform side, for example by rolling back a release. We then work with your developers on the permanent fix and document the cause in writing.
What do you need from us to start?
Access to the cluster, the Hetzner project and your repositories, a short description of the system, a list of authorised people and time with the engineers who know the setup today.
Keep the cluster. Hand over the pager.
Tell us how your cluster is built and what worries you about it. We reply within one business day and propose an audit scope and next steps in writing. No commitment.