Most of what this platform promises, apps that restart themselves, updates that do not take the service down, tenants that cannot interfere with each other, comes down to one piece of software: Kubernetes. This page explains what it is and what it does for you, in plain English, and then describes exactly how we run it.

What Kubernetes is, in plain English

Traditionally, an application ran on a specific server. If that server failed, the application was down until a person noticed, diagnosed the problem and restarted things. The server was a pet: hand-fed, unique, and a single point of failure.

Kubernetes replaces that arrangement. It is an open source system, originally designed at Google and now maintained by the Cloud Native Computing Foundation, for running applications packaged as containers across a fleet of machines. The idea at its core is simple to state: instead of telling servers what to do, you declare what should be true. "This app should always be running, at this size, with this storage attached." Kubernetes then works continuously to make reality match the declaration, on whichever machines currently have room.

That one shift, from instructions to declarations, is what makes everything below possible.

Why that matters when you are the customer

Apps restart themselves. Kubernetes constantly checks that every application is alive and healthy. If an app crashes, it is restarted. If the machine it was running on fails, the app is rescheduled onto a healthy one. This is what the Kubernetes project calls self-healing, and it happens in seconds, automatically, at three in the morning, with nobody paged. A whole class of outage that used to require a human simply does not any more.

Updates roll, they do not cut over. When an app is upgraded, Kubernetes does not stop the old version and start the new one. It brings up new instances alongside the old, checks they are actually healthy, moves traffic across, and only then retires the old ones. If the new version fails its health checks, the rollout stops and can be rolled back. Patching, which is the single most important routine security activity in hosting, stops being a scheduled outage.

One bad app cannot eat the platform. Kubernetes divides a cluster into namespaces, and lets each namespace be given a resource quota (how much compute and memory it may use) and a network policy (what it may talk to). On the Node Platform, every tenant is its own namespace with its own quota and its own network policy. An app that runs away with memory hits its own tenant's ceiling, not yours. Another customer's traffic has no network route to your apps at all. Isolation is structural, enforced by the machinery itself, rather than a paragraph in a contract.

How we run it

The version of this that runs the Node Platform is described in full in how the Node Platform is built; the short version:

  • We run k3s, a lightweight, CNCF-certified Kubernetes distribution, across virtual machines on Proxmox, on hardware we own in a UK datacentre. Certified matters: it is standard Kubernetes, passing the same conformance tests as any other distribution, just packaged with fewer moving parts to operate.
  • Every customer gets a dedicated namespace with its own network policy, resource quota and storage. Your storage volumes are provisioned from our TrueNAS layer, and your login sits in your own Keycloak identity realm, so the isolation runs from the network up through identity.
  • Nothing is changed by hand. The entire platform is described in one Git repository. A change is a reviewed commit, and Argo CD reconciles it onto the cluster automatically, correcting any drift between what is running and what Git says should be running. Two engineers can operate an estate this size safely because the system, not memory, holds the configuration.
  • It is watched continuously. Metrics flow to Prometheus and Grafana, availability to Zabbix, and external uptime checks run on Uptime Kuma, so a workload that is restarting too often gets an engineer's attention rather than silently flapping.
  • We live on it. Node Digital's own files, CRM, email and helpdesk run in a tenant namespace exactly like yours, so every property described on this page is one our own company depends on daily.

None of this requires anything from you. Kubernetes is the reason the platform behaves the way it does; using it well is our job, and the point of this page is simply that you should not have to take that on faith.

This page is part of Under the hood, our series explaining the platform one honest layer at a time. For the full tour of the stack, read how the Node Platform is built.

Frequently asked questions

Do I need to know anything about Kubernetes to use the Node Platform?

No. Kubernetes is our tooling, not yours. You choose apps in the portal, your team signs in and uses them, and the orchestration underneath is entirely our job. This page exists because we think buyers deserve to know how the service works, not because you will ever have to operate it.

What actually happens when one of my apps crashes?

Kubernetes notices that the app is no longer healthy and starts a replacement automatically, usually within seconds and without a human involved. Your data is unaffected because it lives on persistent storage, separate from the running app. If an app keeps failing rather than recovering, our monitoring flags it and an engineer investigates.

Will I see downtime when apps are updated or patched?

Updates are rolled through rather than switched over: new instances are started, checked for health, and traffic moves across before old instances are removed. Where an application's own design supports it, that means no visible interruption. Some upstream apps require a brief restart for certain upgrades, and where that is true we say so and schedule sensibly rather than pretending otherwise.

Can another customer's app slow down or reach my apps?

No. Every tenant runs in its own Kubernetes namespace with its own network policy and resource quota. The network policy means another tenant's traffic has no route to your apps, and the quota means a busy neighbour cannot starve yours of compute or memory. This is enforced by the platform itself, not promised in a contract.

Why do you run k3s rather than full Kubernetes?

k3s is full Kubernetes: it is a CNCF-certified distribution that packages standard Kubernetes as a single lightweight binary. Certified means it passes the same conformance tests as any other distribution, so we get the standard API and behaviour with fewer moving parts to operate, which suits a platform run by a small team that automates heavily.