KubeNest

Kubernetes on the servers you already own, with the maintenance handled.

Standing a cluster up is the easy day. What costs you is everything after: the upgrade nobody wants to run, the backup nobody has restored, the certificate that expires while the person who set it up is on holiday, the kernel patch that never gets applied.

KubeNest is a tested, versioned platform bundle — Kubernetes plus the ingress, storage, certificate, backup and patching components every cluster needs anyway — installed as one thing, upgraded as one thing, carrying one version number for the whole set.

Quickstart Day 2 Why these choices Prerequisites

What you actually get

One version number for the whole platform. Not eight component upgrades you sequence yourself and hope about. Platform 1.0 → 1.1 is a single tested transition, and what changed between any two versions is in the bundle manifest.

Upgrades that check before they run. Every upgrade scans your workloads for Kubernetes APIs removed in the target version and refuses to start if it finds any — because an upgrade that cleanly upgrades the cluster and silently breaks your application has actively harmed you. The ordering puts the irreversible step last, so most failures happen while retreating is still cheap.

Backups that have been restored. A backup nobody has restored is not a backup. Weekly restore drills restore into a scratch namespace, verify objects and volume bytes match, tear it down and record the result. A failed drill is an alert, and it blocks the next upgrade.

The machines get patched too. Ubuntu security updates apply automatically; reboots are coordinated one node at a time inside a window you choose. Unpatched kernels are not a Kubernetes problem, which is exactly why they get left.

Someone notices before you do. Fleet telemetry reports cluster health, bundle version and backup state continuously, so a cluster that has never taken a backup is visible rather than silent.

Deploying apps, when you want it. One file describes a web tier, a worker and a PostgreSQL addon; kubenest deploy puts them up with the connection strings already wired, on a URL with a real certificate, with an audit trail and a rollback.


components:
  api:
    image: myorg/api:v1.2.0
    port: 8000
    expose: api.acme.com
    env:
      DATABASE_URL: ${postgres.dsn}
  postgres:
    addon: postgres@16

Not supported by the current release. kubenest deploy and the rest of the app layer were removed from the command tree and are frozen scope under decision D1. The released CLI installs and operates the platform; this callout comes off only when a release that lifts that decision is promoted.

The honest comparison

Some of these are good products, and for some teams they are the right answer. Here is where each one stops.

Instead of KubeNest	Where it stops
EKS, GKE, AKS	They run the coordination layer in the middle — genuinely hard, and a small part. Everything your applications actually touch is still yours to choose, connect and maintain, on their hardware in their region
Rancher	A good control panel, and looking at your clusters was never the hard part. It does not decide which networking, storage, certificate or backup tools you run, or promise they survive the next upgrade together. Its automated maintenance features are a paid tier
Omni or Talos	Well-built, and they require their own operating system on your machines. If you run Ubuntu today, that is a migration project before you see any benefit
Headlamp, k9s, Lens	Free, light, good at what they do — a view onto a cluster, with no fleet view and no day-2 automation
Hiring a platform engineer	You should, past a certain size. It costs more, takes months to recruit and months more to become useful, and the knowledge leaves when they do
Carrying on as you are	Works, right up until a certificate expires on a holiday or an upgrade needs a maintenance window nobody wants to own

The assembly problem is the product. Every cluster needs ingress, certificates, storage, backup, upgrade orchestration and OS patch handling — and somebody has to pick each one, wire them together, and own whether they still work after the next upgrade.

How it works

You never upload a kubeconfig. The agent runs inside your cluster with its own in-cluster access, and application, addon and component-secret operations flow through the hub to it as signed, schema-validated events.

Every workload is deployed by the agent on its own cluster: the control plane sends the intent through the hub, and the agent on that cluster creates the Argo CD Application. A stack’s components all run on the stack’s cluster. Architecture has the detail.

The agent dials out to the hub, so that session needs no inbound rule at all and survives NAT and egress-only firewalls. (Serving your own traffic is separate — that needs 80 and 443 open, like anything else on the internet.)

Architecture has the full picture.

Next steps

Quickstart — one host, one command, a running app
Day 2 — the upgrades, drills and patching that are the reason to run this
Why these choices — and what we deliberately did not build
Connect a cluster — existing clusters are not supported yet, and why