+--------------------------------------------------+
| TDK CLI |
| one service.json -> tdk up |
| local Docker + Tilt, no Kubernetes on the laptop|
+--------------------------------------------------+
service.json
|
v
+------------------+
| tdk up |
+------------------+
| | |
v v v
Dockerfile Tilt Traefik / proxy
nginx conf env generated client
[ service.json ] --you own this
[ .autogenerated/ ] --TDK writes this
[ helm / argo / kustomize ] --still yours for prod
```
This is a local-dev contract, not another deploy tool: one `service.json` per service, then `tdk up` generates the Docker + Tilt loop (Dockerfiles, nginx, env, Vite/TS config, API client) and brings the stack up on plain Docker. Production stays with Helm / Argo CD / Kustomize.
The interesting bit is the boundary. You keep the manifest; the runtime files are generated and can be drift-checked. `tdk doctor` covers local readiness, and a `smoke` block can hit the public URL after `tdk up` so a green container is not mistaken for a working route.
ERP fixture scale run on a clean GitHub-hosted runner (4 vCPU, 15 GB RAM), snapshot from run 39160719471. The live status is in the ERP fixture scale E2E
8 comments
[ 0.18 ms ] story [ 40.0 ms ] threadThis is a local-dev contract, not another deploy tool: one `service.json` per service, then `tdk up` generates the Docker + Tilt loop (Dockerfiles, nginx, env, Vite/TS config, API client) and brings the stack up on plain Docker. Production stays with Helm / Argo CD / Kustomize.
The interesting bit is the boundary. You keep the manifest; the runtime files are generated and can be drift-checked. `tdk doctor` covers local readiness, and a `smoke` block can hit the public URL after `tdk up` so a green container is not mistaken for a working route.
Repo: https://github.com/tdk-landscape/tdk-cli-core
Install path they document: `curl -fsSL https://tdk-landscape.github.io/install.sh | sh` then `tdk doctor` / `tdk up`. Core CLI is MIT, no key required.