Enterprise orchestration.
No Kubernetes required.

How these numbers and claims were arrived at

1. Geographic data residency is a placement filter, and it ships switched off. A deployment carries odysseus.io/data-residency-country — an ISO 3166-1 alpha-2 code such as CA or DE — or odysseus.io/data-residency-region, which names an operator-defined set of those codes, or odysseus.io/blocked-countries. The scheduler compares each against the node’s own country and region labels before it places anything, and a node that does not satisfy the requirement is dropped from the candidate set — so the deployment cannot land outside its permitted geography, rather than being found there afterwards. It is switched on per installation in the control plane’s configuration and is off by default; the regions are the operator’s own definitions, not ours. Kubernetes can express the same constraint: it ships topology.kubernetes.io/region and topology.kubernetes.io/zone as well-known node labels, and node affinity to select on them, but no country or residency label of its own — so residency there is assembled from custom labels and affinity rules — kubernetes.io. The difference is where the concept lives, not whether it can be done.
2. Odysseus memory figures are measured, not modelled. Both are resident memory (RSS) of the running process, sampled over a 14-minute window on 20 August 2026 across two live installations: production (control plane 47–51 MB over 19 samples, node agent 26–28 MB) and development (control plane 49–64 MB over 18 samples, node agent 26–28 MB). The control plane runs once per installation; the agent runs once per node. The control plane publishes the figure itself as process_resident_memory_bytes on its Prometheus /metrics endpoint, so it can be checked directly rather than taken on trust. We quote RSS rather than docker stats because the latter includes reclaimable page cache, which on a freshly started container reads several times higher without any of it belonging to the orchestrator. The Kubernetes figure is the documented minimum in the upstream kubeadm install guide: “2 GB or more of RAM per machine” — kubernetes.io.
3. Per-node comparison. Upstream Kubernetes publishes no default reserve for its node agents — kubeReserved and systemReserved both ship empty — so there is no single official number to quote. The profiled figure is SUSE’s published K3s resource profiling, which puts the Kubernetes components on an agent (worker) node — its words, “the kubelet and k3s agent” — at 275 MB on an Intel 8375C, from 95th-percentile readings at steady state — docs.k3s.io. K3s is a single merged binary with its own embedded runtime, so this is a floor for upstream Kubernetes running the same components as separate processes, not an equivalent. The reserved figures are capacity that managed providers withhold from every worker node before any application container is scheduled, computed from their own published formulas: AWS EKS reserves (11 × max-pods) + 255 MiB (574 MiB on an m5.large, which supports 29 pods) — docs.aws.amazon.com; Google GKE reserves 25% of the first 4 GiB and 20% of the next 4 GiB plus 100 MiB (≈1.9 GiB on an 8 GiB node) — cloud.google.com. Reserved capacity is an allowance the scheduler withholds, not measured consumption; we label it as such because the two are not the same thing.
4. Container counts are per node, and ours is a statement of fit, not a cap. Odysseus is built for the range where Docker Compose runs out of road and Kubernetes is more machinery than the job needs. The largest figure we have actually run is 82 containers across two tenants on a single node, in our own development installation, counted with docker ps --filter label=odysseus.managed=true on the date above; our production platform node carries 4, which is a small node rather than a limit. A platform total is that per-node figure across however many nodes a control plane manages — an architectural consequence, not something we have measured at fleet scale, so we publish the per-node number we have demonstrated and no fleet number we have not. The Kubernetes figure is that project’s own documented ceiling for a supported cluster: “No more than 110 pods per node”, stated alongside “No more than 5,000 nodes” and “No more than 300,000 total containers” — kubernetes.io. The two columns do not count the same unit — Kubernetes limits pods, a pod holds one or more containers, and we count containers — so read them as adjacent rather than interchangeable. We do not convert between them, because the ratio depends on how the pods are built. Managed distributions cap lower again: AWS EKS derives the per-node pod cap from the machine’s network interfaces rather than from that documented figure, and its own worked example is 29 pods on a two-vCPU machine — the document cited in note 3.