Engineering documents from the cMCP pilot build (October 2026). Statuses here are engineering states, not product claims: see cMCP for what is available. All documents
Status 2026-10-11. The first dedicated GPU server is chosen: a Hetzner GEX45 (one RTX PRO 4000 Blackwell SFF, 24 GB). Stages 1a–1t of Build Phase 1 are built and tested (1l–1s on 2026-10-11, M-109; 1t, M-111). The pilot company has not adopted cMCP, so its account is now a test account with its company data cleared. Next, on hold until the owner resumes it (M-112): the web console moves to cmcp.it-labs.in and the API, sign-in, database and local AI model to a GPU server, so the addresses on this page will change. See the build plan, section 15.

← cMCP master page

Scalability fact sheet

Can the cMCP shared memory layer serve very large companies — a major shipbuilder or a car maker the size of Stellantis — and many such companies at once? This sheet separates what the core design already provides from the tooling we will build when a large client arrives.

Yes — the core design is built for this scale.

Tenant separation, permissions, client walls, memory scopes and model independence do not change with size. What changes is how the software is run: more copies, a database cluster, GPU servers and one isolated "cell" per large client. That is planned engineering on the same design, not a rewrite.

Today cMCP (Build Phase 1, stages 1a–1t) runs for testing on one shared server, on the CPU. Next it moves to its own GPU server (Hetzner GEX45, one 24 GB card), the size of the "GPU server" in the pilot line below. Before we state the large-scale numbers as proven to a client, we will confirm them with a load test on synthetic data (10 million → 100 million facts, 250,000 people).

Two sizing examples

Large shipbuilder

Staff
5,000 – 20,000
Active AI users
1,000 – 3,000
Sources
PLM, ERP, quality / NCR reports, welding procedures, class rules, drawings (OCR)
Special needs
Export control, often no internet (air-gapped), separate install for classified programmes, several languages
Deployment
On their premises (Option C)

Stellantis-sized car maker

Staff
about 250,000, 14 brands
Active AI users
about 50,000
Daily load
~1 million texts to learn from, ~5 million searches (peak ~300 per second)
Special needs
Own SSO, own encryption keys, data kept in its region, brands as separate organisations under one account
Deployment
In their cloud, run by us (Option B)

Company names are used only to illustrate size. Figures are planning estimates, not client statements.

Why the design holds at that size

Design elementWhat it gives a large clientStatus
Account → organisations → teams, projects, clients, peopleA group with many brands or shipyards is one account with several organisations; each keeps its own rules, shared where allowed.in the design
Database-enforced separation (row-level security)Every record carries its account; the database itself refuses cross-company reads, not just the application.in the design
Client walls and private spaces in their own search storesA naval programme or a supplier's data can be kept apart, moved or deleted in one step.in the design
Cheap, cached permission checkEvery request is checked; measured 0.8 ms for the "up to date?" check at 10,000 people.measured
Stateless programs, shared cache, safe job queueAPI, web and workers can run as many copies as needed; sessions and caches are shared, jobs are never taken twice.in the design
Model-independent language layerA GPU cluster or a client-approved model replaces the CPU model by configuration; on-prem models for air-gapped yards.in the design
Open standards (MCP, REST, OpenID Connect)Works with the client's AI tools and their own sign-in system.in the design
Full audit trail, approvals, retention rulesWhat compliance teams in regulated industries ask for first.in the design

How we serve many large clients: one cell each

Each large client gets a complete, separate copy of cMCP — a cell — in its own cloud account or on its own premises. Smaller clients share a pooled cell. Same software everywhere; one client's load or incident can never touch another's.

Cell: car makertheir cloud, their region, their keys
Cell: shipbuilderon premises, no internet
Cell: shipbuilder — classifiedseparate install per programme
Pooled cellmany smaller companies, separated by the database

What we build when a large client arrives

Tool / stepWhy it is needed at scaleStatus
Kubernetes / Helm packagingRun several copies of every part, update without downtimebuild when needed
GPU server pool for learning from textHundreds of thousands of texts a day instead of a few thousand on CPU; better quality on long textsbuild when needed
Database cluster, monthly table partitions, connection poolingStandby copy for failure, fast audit and usage history at millions of events a daybuild when needed
Search engine at hundreds of millions of factsLoad-tested at size; our own interface lets us swap in a dedicated vector database if neededprove by load test
Client SSO + automatic user provisioning (SCIM)250,000 accounts managed from the client's own directorybuild when needed
Client-held encryption keys (BYOK), clustered key vaultRequired by large regulated clientsbuild when needed
Penetration test, SOC 2Proof for client security teamsbuild when needed

Indicative hardware per cell

LayerShipbuilder (on premises)Stellantis-sized (cloud)
Application (API, web, workers, sign-in)3 servers · 32 cores · 128 GB6 – 10 servers · 32 cores
Database2 servers · 32–64 cores · 256–512 GB · 16 TB NVMe3-node cluster · 64 cores · 512 GB, plus a vector-search cluster (3–5 TB growth a year)
GPU (learning from text, search ranking, OCR)2 servers · one 96 GB or two 48 GB cards6 – 10 servers · 1–2 large cards each
Backup30–50 TB + off-site copyCloud object storage, cross-region copy
Pilot to start1 application + database server and 1 GPU server, for one shipyard or one brand (200–500 users)

Estimates for planning. The biggest drivers are: whole mailboxes imported or not, years of old documents loaded at the start, classified work, and whether the service must survive the loss of a server.

Path to a large client

  1. Load test the current design on synthetic data at 10 → 100 million facts and 250,000 people.
  2. GPU benchmark for learning from text at client volume. A first estimate for the GEX45 is in the LLM results, section 6; it is measured once that server is rented.
  3. Pilot with one shipyard or one brand on the pilot hardware.
  4. Build the scale tooling above, then grow the cell to full size.