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. Nomad needs no such assembly and this row is not a differentiator against it: region and datacenter are first-class in its architecture, and a job constrains placement on ${node.datacenter}, ${node.region} or any operator-set ${meta.<key>} value. What differs there is vocabulary rather than power — ours is a named residency label carrying ISO country codes and region membership, theirs a general-purpose constraint pointed at whatever the operator wrote on the node.
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. The range describes where Odysseus is designed to sit — above the point where Docker Compose runs out of road, below the point where Kubernetes earns its complexity. It is positioning, not a benchmark result, and we do not present it as one. 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 no fleet number either. 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. Nomad publishes no per-node ceiling at all, which is why its cell says so rather than carrying a figure. The largest run HashiCorp publishes is its own demonstration: 2,000,000 containers across 6,100 clients — Nomad’s word for a node running its agent — in 10 AWS regions, scheduled in 22 minutes by three servers — hashicorp.com — an average of about 330 containers per client. That is a demonstration rather than a supported limit, and it is a larger number than anything we have run.
5. The Nomad column is sourced, and it wins several rows. Nomad is the nearest peer to Odysseus in this table — a single binary, light on resources, and built to integrate with the same Consul this platform runs on — so a framing that works against Kubernetes would be unfair here, and we have not used one. Rolling updates, canaries with auto_promote, automatic revert of a failed deployment and reverting to the last stable job are all in the job specification’s update block in the Community Edition — developer.hashicorp.com. Autoscaling is real, and arrives as a second daemon to run: the Nomad Autoscaler is “built and released separately to Nomad”, covers horizontal application and cluster scaling, and reads Prometheus among its metrics sources — developer.hashicorp.com. Secret handling is at least our equal: a task’s secrets/ directory is backed by an in-memory filesystem and mounted noexec — developer.hashicorp.com. ACL policies and roles are Community Edition. What is not: audit logging, resource quotas and Sentinel policy are Nomad Enterprise, as is deploying one job across federated regions — federating the regions themselves is not — developer.hashicorp.com. Namespaces are Community Edition, and they segment jobs, allocations, deployments and evaluations; the documentation is explicit that “Nomad does not namespace objects that are shared across multiple namespaces. This includes nodes” — developer.hashicorp.com. Kubernetes draws the same line — “low-level resources, such as Nodes … are not in any namespace” — kubernetes.io; on this platform a node is enrolled to a tenant, which is what that row records. The server figure is HashiCorp’s own reference architecture — “A Nomad cluster typically comprises three or five servers”, at 2–4 cores and 8–16 GB of memory each for a small production deployment — developer.hashicorp.com. That is machine sizing a reader should treat the way we treat the Kubernetes figure in note 2: a recommendation, not measured process memory. We found no published figure for the client agent, so the column says there is none rather than guessing at one, and the row on learning curve is our estimate rather than anyone’s measurement.