№ A / Architecture · internal reference
How it is actually built. No marketing layer.
Two infrastructure patterns, one stack. The same components run for every customer; what changes is whether they share a cluster with other customers (Core) or get a cluster of their own (Mesh and Fleet). This page is for review. It is not in the navigation.
№ A1 / Macro shape
Two patterns,
one stack.
Every component listed below is the same in either pattern. The only difference is the blast radius and the noisy-neighbour story. Core customers share a cluster with namespace isolation; Mesh and Fleet customers get their own k3s, on their own Contabo nodes, with no co-tenants.
№ 01 · Core tier
Mutualized k8s on Contabo
One full upstream Kubernetes cluster (HA control plane on three nodes) shared across small Core-tier customers. Each customer gets a set of Kubernetes namespaces (one per service) with their own Nubus, their own apps, their own ingress hostnames. Hardware is a fixed pool of Contabo VPS + VDS nodes; customers are scheduled across them by k8s.
- → Cheapest per-user economics.
- → Namespace + NetworkPolicy + ResourceQuota isolation, one ns per service per tenant.
- → One operator, one upgrade window. All Core tenants ride the same release train.
- → Shared smallstep sub-CA per cluster, cert-namespaced per tenant.
- → Portable to managed k8s (EKS / GKE / AKS) when scale demands it.
№ 02 · Mesh & Fleet tiers
Dedicated k3s per customer
One k3s cluster per customer, on their own pool of Contabo nodes (currently Nürnberg, DE, the EU region Contabo serves). Argo CD reconciles the customer's namespace from a per-customer branch in the platform repo.
- → Hard isolation: a noisy neighbour is, by definition, only the customer's own workload.
- → Their own offline-root-signed intermediate CA, theirs to keep on churn.
- → Independent upgrade cadence, can be aligned with their compliance windows.
- → Fleet tier adds device management + Wi-Fi/VPN cert issuance + SSH CA.
№ A2 / Inside one customer slice
What actually
runs in there.
Whether the slice is a namespace in the shared cluster (Core) or a whole cluster on its own (Mesh / Fleet), the same set of components run inside it. Identity is provided by Nubus, applications are OpenDesk's, devices are managed by Fleet, certificates come from smallstep, and the laptops reach in via WireGuard.
Component
Role
Where
Nubus IAM
Identity directory + Kerberos KDC + Keycloak SSO
OpenLDAP carries POSIX, Kerberos and Samba schema on every account. One credential drives OS login, app SSO and admin tooling.
k8s
OpenDesk apps
Mail · files · chat · video · docs · wiki · projects
Open-Xchange, Nextcloud, Element/Synapse, Jitsi, Collabora, XWiki, OpenProject, CryptPad, Impress. Mail / calendar / contacts / tasks via OX, files via Nextcloud, chat via Synapse. All federated against Nubus' Keycloak.
k8s · split VPS / VDS
Fleet
Endpoint management + osquery telemetry
Inventory, configuration profiles, patches, scripts, compliance queries. Driven by GitOps via fleetctl. One Fleet per customer slice.
k8s
smallstep CA
Device PKI · ACME · SCEP · SSH certs
Per-customer intermediate, issuing 24h device certs that auto-rotate. Wi-Fi 802.1X, mTLS, VPN auth, SSH user/host certs all flow from here.
k8s
WireGuard
Persistent tunnel from each laptop
LDAP and Kerberos are never exposed publicly. Laptops dial into the customer's WG endpoint and see Nubus only over the tunnel.
k8s · UDP ingress
Headscale
Mesh tailnet for admin & site-to-site
Coordination plane for the customer's internal services and admin reach. Self-hosted, no Tailscale dependency.
k8s
cert-manager
Public TLS for every ingress
ACME against Let's Encrypt, auto-renewal. Strictly for service hostnames, separate from the device PKI above.
k8s
"k8s" above means upstream Kubernetes for the Core tier (one shared cluster) and k3s for Mesh / Fleet (one dedicated cluster per customer). "Per customer" smallstep is true for Mesh / Fleet; Core customers share one sub-CA with namespace-scoped provisioners.
№ A3 / Price-performance trade, by tier
What runs where,
tier by tier.
Two Contabo SKUs power the cluster: cheap shared-hardware VPS (~€1× per core, variable CPU steal), and dedicated-core VDS (~€3× per core, bounded jitter). Mail, files and wikis don't notice steal time, so VPS. Real-time chat, voice and video do, so VDS. Below: the workloads at each tier and where on the hardware they land.
VPS · price-optimized
~€1× / core
VDS · latency-optimized
~€3× / core
Core
- → Nubus IAM: OpenLDAP + Heimdal KDC + Keycloak + UDM + portal
- → Open-Xchange App Suite: mail, calendar, contacts, tasks
- → Nextcloud: file sync
- → OpenProject: projects & tasks
- → XWiki: knowledge base
- → CryptPad / Impress: notes
- → Postfix mail relay
- → Shared databases: postgres, mariadb, redis
- → minio: object storage
- → Vaultwarden: shared password manager
- → cert-manager + ingress-nginx
- → Argo CD
- → Restic backups: daily, off-site EU copy
- → Onyx workspace + connectors to Mail / Files / Wiki / Projects / Calendar / meeting transcripts (Intelligence add-on, only when intelligence: true, see ADR-12)
- → Synapse: Matrix homeserver, chat fan-out
- → Jitsi videobridge + Prosody: real-time voice / video
- → Skynet + Jigasi + Voxtral pipeline: meeting transcription & live captions (Intelligence add-on, only when intelligence: true)
- → Collabora Online: real-time co-editing
- → Live-collab websocket gateway
Mesh
- → smallstep intermediate CA: per customer, signed by the MSP offline root
- → Fleet Server: endpoint management API
- → WireGuard endpoint: persistent laptop tunnel
- → Headscale: admin / site-to-site mesh coordination
·
Fleet
- → FreeRADIUS: Wi-Fi 802.1X EAP-TLS at the customer office
- → Bootstrap endpoint: OEM serial-bound first-boot claim service
- → Extended observability: Prometheus + Loki + Grafana with longer retention
- → Audit-report generator: cron-based quarterly compliance reports
·
Workloads are pinned to node classes via Kubernetes node labels and pod nodeSelectors. The split is the same whether the cluster is mutualized (Core) or dedicated (Mesh / Fleet). Only the absolute size of each pool changes. Tiers are cumulative: Mesh = Core baseline + Mesh adds; Fleet = Core baseline + Mesh adds + Fleet adds.
№ A4 / Trust hierarchy
One offline root,
one intermediate per customer.
The MSP root never touches the network. It lives on a YubiKey in a safe and signs each customer's intermediate exactly once at onboarding. From that intermediate, the customer's smallstep CA issues short-lived certs to laptops, services, and SSH sessions, all auto-rotating, all auditable.
Tier
Who holds it
Lifetime
State
Root
MSP
Signs each customer intermediate, ~once a year
20 years
Offline · YubiKey 5 in a safe
Intermediate
Per customer (Mesh / Fleet)
Issues device, service, SSH certs via provisioners
5 years
Online · in customer's k3s namespace
Leaf
Devices · services · users
Auto-renews via step daemon / cert-manager
24h – 90d
On the endpoint or pod
On churn, the customer's intermediate is revoked at root level. Every cert it issued is dead within the day. Or, if they ask for it, the intermediate's key is handed over with a copy of the root cert and they walk away with a working PKI.
№ A5 / On the laptop
What ships
on the device.
Every laptop we sell goes out with the same image. First boot brings up WireGuard, enrolls into Fleet, requests its first device certificate, and configures SSSD against the customer's Nubus. After that, the user logs in with their OpenDesk credential and never sees a second password screen.
Ubuntu LTS
Stock distro. CIS-Level-1 hardened via Ansible roles applied at first boot.
SSSD
Binds to Nubus over the WG tunnel. POSIX + Kerberos schema lets users log in with their OpenDesk credential. Cached for offline.
Fleet agent
Reports inventory + osquery telemetry, applies config profiles, runs scheduled scripts, orchestrates patches.
step daemon
Holds the device's enrollment credential. Requests a 24h cert from the customer's smallstep CA. Renews every 12h.
WireGuard client
Persistent tunnel to the customer's WG endpoint. Brought up by NetworkManager before user login. No tunnel = no LDAP.
NetworkManager
Consumes the device cert for Wi-Fi 802.1X (EAP-TLS) and VPN. No password Wi-Fi, no shared secrets.
Firefox + Kerberos
Browser is configured to forward the Kerberos TGT from the OS session. Result: open portal.<customer>.* and you're already in.
OpenDesk launchers
Per-app Chromium windows for the OX groupware (Mail / Calendar / Contacts / Tasks in one window with internal tabs), Files, Meet, Projects, Wiki, Notes. Element Desktop for Chat (real native app), Nextcloud Sync alongside Files for the filesystem layer. SSO inherits from the Kerberos session via SPNEGO.
№ A6 / One login, traced
From lid-open
to working,
in eight hops.
A walk through what happens when a real human opens a real laptop on a hotel Wi-Fi.
01
NetworkManager joins Wi-Fi
Using the device cert from smallstep over EAP-TLS. No PSK, no captive portal hell.
02
WireGuard tunnel comes up
Pre-shared key was provisioned at first boot. No user interaction. Customer's services are now reachable, nothing else is.
03
Login screen appears
User types firstname.lastname + their OpenDesk password.
04
SSSD validates against Nubus
Over the WG tunnel: bind to LDAP, fetch the password hash, compare. Cached for offline next time.
05
Kerberos TGT issued
Heimdal KDC inside Nubus signs a ticket. Cached in the user session.
06
Browser opens portal
Firefox forwards the Kerberos ticket to portal.<customer>. Keycloak accepts it as proof. Single sign-on into every OpenDesk app.
07
Mail app launches
User clicks the OX groupware icon in the dock. Chromium-app window opens at mail.od.<customer>, picks up the same Kerberos session via SPNEGO, no prompt. Calendar, Contacts and Tasks are tabs inside the same window. Same SPNEGO-silent launch for Files and Meet, one click each. Chat opens in Element Desktop, authenticated separately at install.
08
Fleet agent reports in
In the background, inventory pushed, policies pulled, scheduled patches checked. Operator sees device green within seconds.
№ A7 / How tiers map to architecture
The same components,
arranged for the price point.
Tier
Cluster
PKI
Devices
Core
Mutualized k8s on Contabo · namespaces per service per tenant · VPS + VDS pool
Shared sub-CA · namespace-scoped provisioners · service certs only
Not in scope · BYO-device or upgrade tier
Mesh
Dedicated k3s per customer · own VPS + VDS pool on Contabo (DE)
Own intermediate signed by MSP root · 5-year rotation · churn-portable
Optional · FleetDM enabled but no laptop sale included
Fleet
Dedicated k3s per customer · own VPS + VDS pool on Contabo (DE)
Own intermediate · device + service + SSH issuance · Wi-Fi 802.1X enrollment
Provisioned laptops · SSSD · Fleet · WG · OpenSCAP hardening · Ubuntu Pro upsell available
Ubuntu Pro (ESM, Livepatch, FIPS) is an optional add-on at the Fleet tier, sold per machine to customers with specific compliance needs, not bundled by default. Default Fleet hardening uses OpenSCAP plus community CIS Ansible roles.
Why this exists
This page is a single source of truth for what the KiwiStack platform actually looks like under the hood. It is intentionally not in the navigation. The rest of the site sells outcomes, not topology. If you arrived here by direct link, you are probably the founder or a prospective enterprise customer doing diligence. Ask hard questions: hello@kiwistack.io.