flisk.sh is a CLI. You describe each service in one service.json. flisk up writes the local wiring and starts that part of the product on your machine.
Docker runs the containers. Tilt live-updates them as you code. Flisk writes the files those two consume: Dockerfiles, Traefik routes, env files, and the Tiltfile. You do not maintain a Compose file for this. You do not boot Kubernetes to change a button. It is not a deploy tool. Production stays on Helm, or on whatever you already ship with.
The package is @flisk-sh/flisk. Older posts say tdk. The binary on the site today is flisk.
The only file you own
A frontend is this:
{
"appName": "orders",
"appType": "frontend",
"port": 3001,
"framework": "vue"
}
A backend is the same idea: name, type, port, stack, health path, what it depends on. That file is the contract. Generated files are output. They land under .autogenerated/. A typical frontend gets about 17 of them: Dockerfile, nginx, env, tsconfig, Vite, an API client, AGENTS.md.
You commit service.json. You do not treat the generated Dockerfile as source. If a person or an agent hand-edits it, flisk config verify fails because the output no longer matches what the CLI would write.
Four commands
Node.js 22.12 or newer. Docker. Tilt. macOS and Linux work directly. Native Windows can inspect. Starting the stack needs Ubuntu on WSL2.
npm install -g @flisk-sh/flisk
mkdir shop && cd shop
flisk project --yes
flisk resource orders-api --type backend --stack shop --yes
flisk doctor
flisk up shop --dry-run
flisk up shop
flisk project creates the repo shape. flisk resource writes the manifest for one service. flisk doctor checks the machine before you burn ten minutes on a missing daemon. flisk up shop --dry-run prints the services and URLs and starts nothing. flisk up shop starts that stack, not the whole company.
Routes land on a local domain such as http://api.shop.localhost/... when port 80 is free. Otherwise the CLI prints a port. Dev ports bind to 127.0.0.1 unless you set TDK_BIND_ADDRESS.
What "the stack starts" means
Flisk is a generator. Tilt is the runner. Docker is the runtime. Traefik is the local front door. Postgres can come up with the stack. Golden base layers exist so the second boot is not a full image rebuild.
That split matters. If you already like Tilt, you are not throwing it away. You are stopping the team from hand-writing the Tiltfile. If you already have a Compose file that fits on one screen, do not add this. A human can keep that file alive. A generator on top of a setup that already works is how a tool gets deleted in week three.
Who it is for
It fits a stack that has outgrown one Compose file and has not earned a local cluster. Twelve services in one file is a different job from twelve services that each own a manifest, a route, and a health check.
It is also for the coding agent. An agent will rewrite a Dockerfile, drift the Tiltfile, and "fix" nginx until the health check is a lie. service.json is the spec it is not supposed to own. .autogenerated/ is the diff you review when it ignored that. The agent framework still owns prompts, tool calls, and retries. Flisk owns the local process. If you do not have that second problem, you do not need this CLI just because you use an agent.
Do not migrate the monorepo. Pick one stack that already hurts. flisk up shop is the feature.
The numbers, with the limits attached
A warm start of 14 tiny services was healthy in 4.6 seconds on a 16 GB M1 after the images already existed. That is not a cold boot. A cold start of a smaller example, images removed, was minutes, not seconds. The site publishes both.
The 100-service figure is a generated /health fixture: small stub services, routed through Traefik, used as a boot test. It is not an ERP. A 20-line health handler at about 17 MiB does not predict a Java API. If your service needs 1 GB, fifty of them do not fit because a stub bench said 1.63 GiB. The daily driver the project talks about is a 14-service stack on that same 16 GB M1. A 27-service monorepo runs on the same engine. Quote those, or do not quote a number.
Onboarding time has not been measured on a hiring cohort. The savings calculator is arithmetic on inputs you type. It is not a measured result.
What you pay
Core is MIT and needs no key. flisk up is in the core. Most teams should stay there.
Premium is $19 per developer per month, optional. It is a feature key for extras: a local Verdaccio registry, a DDD scaffold, idle stop. It is not a support contract, and it is not required to start the stack.
What it will not do
It will not replace Helm, Argo CD, or Kustomize. It will not run your CI. It will not turn the laptop into production. It will not make a 100-service fixture into a capacity plan. It will not help a Compose file that already works.
If the laptop setup already starts the product, keep it.
