Case Study: Real Workloads, One Control Plane

We don't have a customer logo wall yet. What we have instead is our own infrastructure, running production and near-production workloads under Odysseus every day — and we measured it rather than describe it from memory.

The host, measured 21 August 2026

123
Containers under Odysseus management
8 / 23
Cores / GB RAM, single VPS
30d
Host uptime at time of measurement

123 containers is not a synthetic benchmark or a demo cluster spun up to make a number look good — it's the count from docker ps on the box this site's own control plane runs on, at the moment we wrote this page. It includes the workloads below plus everything else this host runs: the control plane itself, the marketing site, monitoring, and unrelated customer projects.

Workload A: a regulated document-processing platform

This tenant's identity is under NDA, so what follows describes the shape of the workload, not who runs it. It is a real, multi-service platform for processing and verifying regulated documents — the kind of stack that would be a full Kubernetes application in most shops, running here as 23 containers under one Odysseus tenant:

That is a microservice architecture with a real dependency graph — a database, an object store, a transparency log with its own five-container topology, and a dozen independently-scaled workers — running as one Odysseus tenant, on one control plane, with no separate orchestrator layered underneath it.

Workload B: a multi-tenant SaaS backend

A second, unrelated tenant on the same host runs 36 containers: backend and frontend services, a document ingestion and extraction pipeline, embeddings, an MCP gateway and builder, a super-admin and tenant-admin console pair (each with its own backend and frontend), MongoDB, Redis, RabbitMQ, and a small internal database-relay cluster of its own. It is a fully separate application with a fully separate shape, isolated from Workload A by the same tenant boundary described on the Compliance page — not a variation on the same stack.

Control-plane overhead at this scale

None of this runs a heavier control plane to manage. Odysseus's own resident memory footprint is measured — not modelled — at 47–51 MB in production and 49–64 MB in development, sampled over a 14-minute window across 18–19 readings per environment on 20 August 2026, published on the homepage's methodology footnote. A spot check on this same host on 21 August 2026 read 57 MB resident — inside that measured range, not a new claim.

What this shows, and what it doesn't

This is one host, not a fleet-scale benchmark, and we present it as that: evidence that Odysseus holds up under a real, multi-service, security-sensitive workload running alongside an unrelated multi-tenant SaaS backend — not a claim about ceilings. For where the platform's control plane runs across genuinely separate infrastructure, see the multi-cloud proof page.

How these numbers and claims were arrived at

  1. Container counts were taken directly from docker ps on the host this site runs on, on 21 August 2026: docker ps -a --format '{{.Names}}' | wc -l for the total, and a name-prefix filter per tenant for the two workload counts. They are not taken from a design document or an earlier description of either stack. Re-run independently a second time the same day: 123 total, 23 and 36 for the two workloads, unchanged.
  2. The specific container names for Workload A and Workload B (the worker list, the transparency-log components, the SaaS backend's service list) were read from the same docker ps output, not assumed from an architecture document, so that a name we could not find running is not listed as if it were.
  3. Control-plane memory is not re-measured on this page. It is quoted from the homepage's own dated, methodology-footnoted figure, with a same-day spot check noted as corroboration rather than presented as a second independent measurement.
  4. Host uptime and core/RAM figures come from uptime, nproc, and free -h run on the same host at the same time as the container counts.