We built this ourselves, and we live in it.
The Node Platform is not a reseller skin over a hyperscaler. We designed and assembled it from the virtualisation up, on hardware we own in UK datacentres, and we run Node Digital itself on it before any customer does. What follows is the honest engineering tour: the software we chose, why we chose it, and how the layers stack together. We think of the whole thing as off grid, deliberately independent of the commercial clouds and SaaS suites most providers quietly rent and mark up. Independence is the point. It is what lets us see every layer, fix any of them, and keep the keys.
This is the engineering companion to Node runs on Node: that page is the plain-English version, the apps we run our own business on and what living inside the platform teaches us; this one is the stack underneath them.
The shape of the system
It helps to picture the platform as a set of layers. Each one has a single job, and each one is chosen so that the layer above it never has to care how the layer below works. At the bottom is metal we own. At the top is your tenant: your apps, your login, your data. Everything in between is the machinery that turns the first into the second.
Compute and virtualisation: Proxmox
Every machine in the estate runs Proxmox VE, an open source virtualisation platform, so that a physical server becomes a pool of virtual machines we can create, move, snapshot and rebuild from a script. Nothing important is a hand-built, one-of-a-kind server. When a node needs work, we drain it and its workloads move; when we need more capacity, we add a node and it joins the pool. Owning the hypervisor rather than renting instances from a hyperscaler is what keeps the layers above it entirely ours.
Storage: TrueNAS
Persistent data lives on TrueNAS, served to workloads over the network as both file and block storage. It is built on the ZFS filesystem, which gives us checksummed integrity, cheap snapshots and efficient replication for free. A running app asks for a volume of a given size and performance tier, and the platform provisions it from TrueNAS without the app, or you, needing to know which disks it landed on. Fast tiers sit on SSD, standard tiers on spinning disk, and the difference shows up only as a line on the rate card.
Orchestration: Kubernetes
The apps themselves run on Kubernetes, specifically the lightweight k3s distribution, which schedules containers across the virtual machines, restarts anything that dies, and keeps each app running at the size it was asked to run at. Kubernetes is also where tenant isolation is enforced: every customer gets a dedicated namespace with its own network policy, resource quota and storage, so one tenant cannot see, reach or starve another. This is structural, not a promise in a contract.
The edge and the traffic
Requests from the outside world arrive through Cloudflare for DNS and edge protection, land on our own nginx and HAProxy load balancers, and are routed to the right app inside the right tenant, each behind its own TLS certificate. Internally, HAProxy also fronts our database clusters so an application talks to one stable address while the cluster behind it fails over, scales or gets patched underneath.
Identity and secrets
One idea holds the whole platform together: every person, service and machine has an identity, and everything checks it.
- Single sign-on runs on Keycloak. Each tenant gets its own isolated realm, so your users, groups and access rules are yours alone and enforced at the identity layer across every app. If you already run Microsoft Entra ID, Google Workspace or LDAP, we federate it in rather than making people learn a new login.
- Secrets never live in a config file or a Git repository. They are generated, stored as Kubernetes secrets, and escrowed into Passbolt, our open source password and secret manager, so there is exactly one place a credential lives and exactly one audited place an engineer retrieves it from.
The data and API plane
This is the machinery that moves work and events around the platform.
- The API and AI gateway is Apache APISIX, which fronts
api.node.uk. It authenticates every call against Keycloak, enforces per-client rate limits, and meters usage so it can be billed accurately and attributed to the exact person or agent that made it. - Event streaming uses an Apache Kafka compatible log (we run Redpanda). Usage events, from an API call to an hour of a running app, flow onto the stream and are consumed by the billing pipeline, so your invoice is assembled from a durable record of what actually happened rather than a nightly guess.
- Data flows and integration run on Apache NiFi, which shuttles and transforms data between systems on schedules and triggers with full lineage, and on tenant automation tools like n8n.
- Billing itself is rated and invoiced by an open source billing engine (KillBill) reading a single published rate card, which is why every app, user and metered unit of AI lands on one predictable bill.
Underneath all of this sit highly available PostgreSQL and MySQL clusters (Patroni and Percona XtraDB), replicated across nodes so a single failure never takes a database offline.
Backup, disaster recovery and failover
Redundancy is designed in at every level, not bolted on as a premium tier. Databases replicate across nodes, storage is snapshotted, and whole tenants are backed up on a schedule with Velero at the cluster level and Kopia or Restic at the app level. Beyond day-to-day backups, we maintain a separate disaster-recovery foundation in a cloud region: an independent, standby target that our data is exported to, so that a loss of a primary site is a recovery we have already rehearsed rather than an emergency we improvise.
Monitoring and observability
We would rather find a problem before you do, so the platform watches itself continuously. Metrics are collected by Prometheus and rendered on Grafana dashboards; availability and infrastructure health are tracked in Zabbix; and simple external uptime checks run on Uptime Kuma. Because we run our own company on the platform, these dashboards are not decoration. They are the first thing an engineer looks at, because our business depends on the same numbers yours does.
Security and the SIEM
Security is layered rather than perimeter-only. Logs from every host and app ship to Wazuh, our open source security information and event management (SIEM) system, which watches for intrusions, file-integrity changes and anomalies across the estate and keeps the audit trail that answers who did what and when. Combined with per-tenant network isolation, identity-checked access on every service, secrets kept out of code entirely, and UK-only data residency by default, the posture is defence in depth: no single control is asked to be the only thing standing between an attacker and your data.
How a change reaches production
The entire platform is described in one Git repository, and that repository is the source of truth. A change is a commit: it is reviewed, merged, and then reconciled onto the cluster automatically by Argo CD, which continuously compares what is running against what Git says should be running and corrects any drift. Nothing important is changed by hand on a live server. This is what lets two engineers operate an estate this size safely: the system, not human memory, holds the definitive picture of how everything is configured.
Our own language models, in the loop
We host our own large language models on our own GPUs, served through the AI Gateway, and we put them to work running the platform. They draft and keep documentation current as the system changes, triage logs, summarise incidents and help with routine engineering, all metered and attributed exactly as customer AI usage is. It is the same catalogue of models any tenant can call, pointed inward. Using what we sell, on the infrastructure we sell it on, is the whole idea.
Everything, in one place
| Concern | What we run |
|---|---|
| Virtualisation | Proxmox VE |
| Storage | TrueNAS (ZFS) |
| Orchestration | Kubernetes (k3s) |
| Load balancing and edge | HAProxy, nginx, Cloudflare |
| Identity and single sign-on | Keycloak |
| Secrets management | Passbolt |
| API and AI gateway | Apache APISIX |
| Event streaming | Apache Kafka compatible (Redpanda) |
| Data flows and integration | Apache NiFi, n8n |
| Databases | PostgreSQL (Patroni), MySQL (Percona XtraDB) |
| Backup and disaster recovery | Velero, Kopia, plus a standby cloud DR foundation |
| Monitoring | Prometheus, Grafana, Zabbix, Uptime Kuma |
| Security and SIEM | Wazuh |
| Deployment | Argo CD (GitOps), Helm |
| AI | Self-hosted models via the AI Gateway |
Go deeper
A few of the areas above reward a longer look. Expand the ones you are curious about.
How is one tenant kept separate from another?
Isolation is enforced at several layers at once, not by policy alone. Each tenant is a dedicated Kubernetes namespace with its own network policy, so traffic cannot cross from one tenant to another. Each has its own resource quota, so a busy neighbour cannot starve your apps of compute or memory. Each has its own identity realm in Keycloak, its own storage volumes on TrueNAS, and its own database instances rather than a shared multi-tenant database. The result is that another customer's workload has no path to your network, your data or your login, by construction.
What happens when we change something in production?
Every change starts as a commit to the Git repository that describes the platform. It is reviewed by an engineer and merged, and Argo CD then reconciles the change onto the cluster and confirms the running state matches what Git declares. If anyone or anything causes the live system to drift from that declaration, Argo CD flags it and can put it back. Because the repository is the single source of truth, we can always answer exactly how any part of the estate is configured, and we can roll a change back by reverting a commit.
How does disaster recovery actually work?
There are three lines of defence. First, live redundancy: databases replicate across nodes and storage is snapshotted, so most failures are absorbed with no data loss and no downtime. Second, backups: whole tenants are backed up on a schedule with Velero at the cluster level and Kopia or Restic at the application level, into object storage. Third, off-site disaster recovery: an independent standby foundation in a separate cloud region receives an exported copy of the data, so the loss of an entire primary site is a recovery we have designed and rehearsed rather than a scramble. Each line covers a different kind of failure, from a single dead disk to a whole-site outage.
Where do secrets and credentials live?
Not in code, and not in the Git repository that describes everything else. Credentials are generated with a cryptographically secure generator, held as Kubernetes secrets that the workloads read at runtime, and escrowed into Passbolt so there is one audited place an engineer can retrieve them from. Keeping secrets entirely out of source control is a deliberate line: the repository can be the complete picture of how the platform is configured precisely because the sensitive values are held separately.
Why run your own language models at all?
Two reasons. The first is residency: a model running on GPUs we own in our own datacentre can process a prompt without that prompt ever leaving our infrastructure, which no US-processing AI provider can offer. The second is that it keeps us honest. The models we sell to customers are the models we use to run the platform, on the same gateway, metered and attributed the same way, so we feel any rough edge in the product before a customer does. It is the AI corner of a wider rule: we use what we sell.
That is the platform, layer by layer. If you would like to run your business on it, start with £25 of free credit, or read how we run our own company on it. Curious about a specific layer? Ask us anything and an engineer will answer.
Questions about the architecture?
If you want to go deeper on any layer of this, tell us what you are curious about and an engineer will answer it directly.