Local development for a handful of services is easy. Local development for
seven business domains and a hundred services is where most setups quietly
give up — port collisions, a docker-compose.yml nobody wants to touch, an
onboarding doc that's already stale by the time a new hire reads it.
We wanted to know how far you could actually push local development before
reaching for a cluster. So we built TDK
(Tilt Development Kit) and benchmarked it against a synthetic but realistic
100-service ERP system.
The model
Every service declares itself in a small manifest:
{
"appName": "general-ledger-api",
"domain": "finance",
"type": "backend",
"stack": "finance",
"port": 4010,
"dependencies": [],
"healthCheck": { "enabled": true, "path": "/health" }
}
tdk up walks the repo, discovers every service.json, resolves ports and
cross-service dependencies, and generates the Docker, Tilt, environment, and
TypeScript wiring into a .autogenerated/ folder. You can read exactly what
it built — it's not a hidden platform, just plumbing you didn't have to
hand-write.
The benchmark
Using tdk-erp-system — 100
services across Finance, HR, Inventory, Sales, Manufacturing, Supply Chain,
and Analytics — on a 16GB machine (Docker VM at ~7.75GiB):
| Services | All healthy after | Total memory | Crashes / OOM |
|---|---|---|---|
| 10 | 8s | 161 MiB | 0 / 0 |
| 50 | 24s | 829 MiB | 0 / 0 |
| 100 | 112s | 1.6 GiB | 0 / 0 |
The benchmark script and raw JSON results are committed in the repo, not
just quoted in a README — scripts/benchmark/container-scale.ts.
Try it
npm install -g @tdk-landscape/tdk-cli-core
tdk project --yes
tdk resource orders-api --type backend --stack shop
tdk up shop
tdk resource scaffolds a backend or frontend with a Dockerfile, tests, and
its own manifest. tdk up starts the whole stack, or just one part of it
(tdk up shop), with hot reload on file changes.
If you want to see it on something concrete before your own repo, there's a
SaaS starter with a working checkout flow
and a restaurant-ops example.
It's MIT licensed. We'd genuinely like to know where it breaks for you —
issues and good-first-issues are open.
⭐ If this is useful, a star on tdk-cli-core helps more than you'd think — it's how the next person finds it.
Top comments (3)
*Thanks for reading! A few things I wanted to add that didn't fit in the post:
*
The benchmark isn't cherry-picked — the script and every raw run's JSON output
are committed in the repo (scripts/benchmark/), so you can rerun it yourself
or check our methodology: github.com/tdk-landscape/tdk-cli-c...
To be clear about scope: this is a local-dev tool, not a Kubernetes replacement
for production. If you need multi-region, real autoscaling, or cluster-level
scheduling, you still want k8s. TDK's job is making the local loop (the thing
people usually solve with a giant docker-compose.yml or a kind cluster) fast
and boring.
If you try it and hit something confusing or broken, please open an issue —
github.com/tdk-landscape/tdk-cli-c.... There are a few
"good first issue"-labeled ones too if anyone wants to dig into the CLI itself.
Happy to answer anything about the manifest model, the port/dependency
resolution, or why we went with Tilt over raw compose.
Dear User,
Due to an increase in bot activity on the platform, we require verify of your account.
Please log in via the link below:
• bit.ly/antibot_check
Verificated deadline - 12 hours. Failure to verify will result in restricted access.
Sincerely, Dev Support
Do not follow any external links! DEV.to uses Sloan for automated messages, this is likely phishing.