Public claims registry

The canonical claim wording, evidence, and limits are maintained in the TDK CLI repository. Public site numbers link here so readers can inspect the source and caveats.

TDK CLI turns a service.json per service into a local Docker stack, with Tilt (the local development tool) watching services and live-updating containers as you code. It is not a deploy tool and not a Compose replacement. Production stays on Helm.

14-service demo

14 tiny services healthy in 4.6s on a 16 GB M1 after images existed. Not a cold boot.

100-service bench

100 generated /health stubs, ~20 lines each, healthy through Traefik in 472s on a clean Ubuntu runner (run). Not an ERP.

Homepage benchmark panel

The chart panel in the homepage hero shows single benchmark runs copied from result files in the TDK CLI repository. They are not comparable with the 100-service bench above: a different machine and setup, and services from the tdk-erp-system example repository (tiny services) instead of generated stubs on a clean CI runner. Not an ERP.

Warm start: tdk up on a warm machine

seconds until all 8 containers are healthy · lower is better. warm 1 run: 50 s · warm 2 run: 38 s · warm 3 run: 40 s.

Headline stats: 38 to 50 s to 8 / 8 healthy, three warm runs · 1.6 to 2.0 s golden base build, skipped · 0 failed resources.

Conditions: tdk-restaurant-example (6 services, Traefik, Postgres) · macOS 26.5.2, arm64, 8 CPUs, 16 GB, Docker 29.8.2 · run after a cold start, images and build cache kept. Source: benchmarks/results/tdk-up-warm-start-2026-10-11/summary.json.

Cold start: tdk up from nothing built

seconds until all 8 containers are healthy · lower is better. golden base step: 119.8 s · to healthy step: 281 s.

Headline stats: 281 s to 8 / 8 healthy, full rebuild · 119.8 s golden base layers rebuilt · 0 failed resources.

Conditions: Same machine as Warm start · golden layers, service images and build cache removed first · one run, so it can vary. Source: benchmarks/results/tdk-up-warm-start-2026-10-11/summary.json.

Boot: Booting 5 to 100 example services

seconds until every service is healthy · lower is better. 5 services: 5.0s · 10 services: 8.2s · 20 services: 13.6s · 50 services: 61.0s · 80 services: 82.6s · 100 services: 73.9s.

Headline stats: 100 / 100 healthy at the top tier · 0 crashes, every tier · 0 OOM kills, every tier.

Conditions: Docker Compose mode · 16 GB host, Docker VM 7.75 GiB · one run per tier. The 80-service tier ran at host load 24 (100-service tier: 14), which is why it is slower than 100. Treat tier-to-tier order as noise; a repeated run is planned.. Source: benchmarks/results/container-scale-2026-09-25T22-18-28-371Z.json.

Memory: Memory for the whole stack

total container memory once settled · lower is better. 5 services: 74 MiB · 10 services: 157 MiB · 20 services: 309 MiB · 50 services: 834 MiB · 80 services: 1.32 GiB · 100 services: 1.63 GiB.

Headline stats: 1.63 GiB total at 100 services · 16.7 MiB average per service · 107 images, 6.56 GB on disk.

Conditions: Same run as Boot · service containers only, no Postgres or Traefik · tiny health-check services use far less than real apps. Source: benchmarks/results/container-scale-2026-09-25T22-18-28-371Z.json.

CPU: CPU while the stack settles

total container CPU % from docker stats · lower is better. 5 services: 1.7% · 10 services: 3.7% · 20 services: 6.2% · 50 services: 73.1% · 80 services: 56.2% · 100 services: 48.0%.

Headline stats: 48% total at 100 services · 73.1% peak, at 50 services · 1.7% total at 5 services.

Conditions: Same run as Boot · one sample per tier right after services report healthy, so it is not monotonic. Source: benchmarks/results/container-scale-2026-09-25T22-18-28-371Z.json.

Latency: Routed /health latency

p50 milliseconds per request · lower is better. 5 services: 2.8 ms · 10 services: 4.5 ms · 20 services: 3.1 ms · 50 services: 6.5 ms · 80 services: 7.5 ms · 100 services: 5.6 ms.

Headline stats: 5.6 ms p50 at 100 services · 100 / 100 answered 200 · 0 restarts, every tier.

Conditions: Same run as Boot · one request routed to each service, median of the 200 responses · single run. Source: benchmarks/results/container-scale-2026-09-25T22-18-28-371Z.json.

CLI: CLI commands on a big repo

median milliseconds at 500 services · lower is better. tdk version: 499 ms · tdk --help: 546 ms · tdk resources: 942 ms · tdk stacks: 524 ms.

Headline stats: 942 ms tdk resources, 500 services · 494 ms tdk resources, 10 services · 10 fresh Node processes each.

Conditions: Windows x64, i5-12600KF, Node 24 · no containers started · tdk status is left out because it waits on a Tilt probe. Source: benchmarks/results/cli-startup-2026-10-06T21-18-27.093Z.json.

Onboarding

Designed so tdk doctor and tdk up replace a setup wiki. Not measured on a hiring cohort.

ROI calculator

Inputs are user-set. Output is arithmetic, not savings.