An enterprise resource planning (ERP) system is a bad place to run everything at once. Finance, HR, inventory, sales, manufacturing, supply chain, and analytics each have their own services, databases, and startup order. Starting all of them by hand is slow, and one wrong port can break the whole chain. [Add your own before-TDK time or incident here.]
This is how I run the ERP example on my laptop now, using TDK CLI. The example repository is tdk-erp-system. It declares about a hundred services across seven domains. I describe the setup from the repository itself, so the numbers below are the ones it contains.
The layout
Each service lives in a folder under its domain, and each folder holds a service.json. The folders are grouped by stack: finance, hr, inventory, sales, manufacturing, supply_chain, and analytics, plus a platform folder for shared infrastructure. The repository has 107 service.json files in all.
A typical manifest is short. For a sales service, it names the app, its type, its stack, its port, its API path, its dependencies, and its health route:
{
"appName": "crm-api",
"appType": "backend",
"stack": "sales",
"port": 4300,
"apiPath": "/api/crm",
"dependsOn": [],
"healthCheckPath": "/health",
"schemaVersion": 1
}
I edit that file, and the rest of the runtime is generated. I do not touch the .autogenerated/ folder, because TDK regenerates it.
The commands I use
I start by checking the machine:
tdk doctor --json
Starting one domain at a time keeps a laptop responsive, so that is the approach this article assumes:
tdk up finance
tdk up hr
Each domain's stack starts with its own services. Cross-domain dependencies are allowed, so a service in one stack can depend on a service in another.
When I want the dashboard, tdk ui shows the services and lets me move between them. tdk logs --json --service <name> --tail 200 gives me recent output for one service, and tdk status --json tells me which services are ready.
What it saved me
The biggest change is that ports stop being my problem. TDK chooses free ports when the defaults are taken, and it prints the choices. Dependencies come from dependsOn, so I do not have to remember which API a worker needs before it starts.
The second change is that hand edits are caught. Generated files are compared with saved snapshots before startup, so a hand edit stops the start and names the file. The fix is in the source. [Add a real example from your own work if you have one.]
The third change is the dry run. Before starting a domain you have changed, tdk up <stack> --dry-run shows the plan without starting anything.
Where it still hurts
Running a hundred services on one laptop is heavy, even in domains. Each container uses memory, and a full stack leaves little room for a browser and an IDE. Run one or two domains at a time, and stop the rest with tdk down. [Add your own machine specs and how many domains you run at once.]
Some of the documentation in the example repo describes the full flow in more detail than this article does. Check it against the version you have, because the example evolves.
What I would tell a new team
Start with one domain, not seven. Make one service run end to end, with its health route and its logs, before you add a second. Keep the manifests small and the dependencies explicit. Use the drift check and the dry run in code review, so a change to a manifest is visible before it starts.
TDK CLI is for local development. Production deployment stays with the team's own tooling, and the example repository leaves that part to you.
Summary
Running an ERP locally used to be a morning of manual startup. Now each domain is a stack, each service is a manifest, and the commands are short. The layout is what makes it work: one service.json per service, generated runtime files, and checks that catch problems before the start.
