I want to share where TDK CLI stands and invite you to take part in it. This is not a launch and it is not a finished product. It is a working tool with real users, real gaps, and a public list of work that needs hands.
What TDK CLI is
TDK CLI is a command-line tool that runs a multi-service application on your machine. You describe each service in a service.json file, and TDK generates the Docker and Tilt files from those descriptions and starts the stack with tdk up. It is for local development. Production deployment stays with tools such as Helm, Argo CD, or Kustomize.
The core CLI is MIT-licensed and needs no key to run.
Where it is honest about its state
The README describes TDK as 1.x for local development. That means the core commands and the service.json model are in use, and the project still changes. Some areas are marked as opt-in, such as the Go and Rust language providers, and some premium features need a license key. Check the docs for the feature you plan to use before you depend on it.
The project publishes its open issues, and a good number are labelled for newcomers. Treat the tracker as the honest record of what is unfinished.
What it does day to day
-
Scaffold services.
tdk resource <name> --type <type>creates frontends, backends, workers, MCP servers, and other resource types. -
Start the stack.
tdk upbuilds and runs the services, andtdk up <stack>starts one part of a larger system. -
Check before it starts.
tdk doctor --jsonreports whether the machine can run the stack.tdk up main --dry-runshows the plan. -
Watch it run.
tdk status --jsonreports readiness,tdk logs --jsongives recent output, andtdk uiopens a terminal dashboard. -
Work with agents.
tdk mcpruns a local Model Context Protocol server, so an assistant can start the stack and read its status.
Ways to take part
If you use TDK, tell us what you built. A short note in the community discussions helps the next person decide whether the tool fits their work.
If you write about it, link to the repository and the docs, and say what you tried. Accurate posts are the most useful ones.
If you want to contribute code, start with the labels. Documentation and translation issues are the usual first step, and tests come next. The contributing guide explains the sign-off rule: every commit needs a Signed-off-by line, added with git commit -s.
If you maintain a project that uses TDK, add it to the list of adopters, so the next team can see who else runs it.
Ways to help without writing code
Report a bug with the exact command, the output, and your version. Improve a translation. Try the example repositories, such as the ERP example, and tell us which part confused you. Read the docs and note where they are unclear.
What we are still working on
Some of the work is visible in the issue tracker: better error messages, more tests, and clearer documentation for newcomers. Some of it is harder, such as keeping generated files consistent across many services. We would rather say that plainly than promise a date.
Join us
Pick one thing from this list and do it this week. Open an issue, fix a typo, or try a stack you have never run. The community is only as useful as the people who show up with something specific to say.
Thanks to everyone who has already opened an issue, sent a pull request, or written about TDK.
