A tool that has been called one thing for a long time gets a new name, and every reference to the old one becomes a question: does my command still work, do my files still match, and where do I file a bug? The TDK CLI is now being renamed Flisk. The project describes itself as a local Docker and Tilt project generator, and the core CLI stays MIT-licensed.
This article sets out what the rename changes, what it leaves alone for now, and how to move an existing project. I read the names from the repository's package metadata and contributor guide in a rename branch. I have not installed the renamed package in this article, so check each command against the release you use.
What changes on the surface
The package moves to the Flisk scope. The package metadata names @flisk-sh/flisk, with a description that reads "Flisk CLI, start services on your machine", a homepage at flisk.sh, and the repository at github.com/flisk-sh/flisk.
The command name is the most visible change. The contributor guide now uses flisk for the commands: flisk resource, flisk up, and flisk status --json. Scripts, README snippets, and agent instructions that say tdk will need updating.
The project's own description also changes. Where the older docs called the tool a local development kit for microservices, the new text says it is a local project generator. The wording is narrower on purpose: it generates local configuration and runs it, and it is not an orchestrator.
What still carries the old name
Not everything changes at once. Several things still use TDK names, and you should not assume they are gone:
-
Environment variables. The governance text still refers to
TDK_LICENSE_KEYfor the premium features. -
Project folders. The contributor guide still refers to
.tdk/and.tdk-out/, and the generated file rules still apply to those folders. - The MCP server name and tool names in existing agent configurations may still use the old name. Check your client config after you update.
If you rely on any of these in scripts or CI, keep them until a release note says they changed. Renaming a variable or a folder breaks every project that reads it.
How to move an existing project
Start with a clean branch, so the change is easy to review and easy to revert:
- Read the release notes for the version you plan to install.
- Install the renamed package, and confirm the command name with
flisk --version. - Run the doctor first, so you know the machine still works:
flisk doctor --json. - Dry-run the stack before any change:
flisk up main --dry-run. Compare the plan with what the old tool printed. - Update the README, your scripts, and your agent instructions to use the new command name.
- Leave the environment variables and folder names alone until the release notes say otherwise.
If the dry run differs from the old one, stop. Find out why before you start containers.
What to tell your team
Say which version you are on, which command names changed, and which names did not. A teammate who updates the tool but keeps the old command in a script will get a confusing error, and the fix is one line in the README.
Also say where to report problems. The project's issue tracker moves with the repository, so link to the new location in your team's notes.
Why rename at all
A name that people cannot say, search, or remember costs a project attention it does not need. A clearer name, with a domain and a package scope that match, makes the tool easier to find and to recommend. The cost is a period of mixed names, which is why the rename should come with clear notes rather than a surprise.
Summary
TDK is becoming Flisk. The command, package, domain, and repository change first. Environment variables and folder names keep their old names for now, and that split is the part most likely to break a script. Move a project on a clean branch, dry-run the plan before you start containers, and update every reference to the command name your team uses.
Top comments (0)