flisk.sh 是小型 CLI，還是多服務本地開發的大問題解法？

People keep asking the wrong size question about flisk.sh.

Is it a platform? A Kubernetes replacement? A new way to build companies?

No. It is a CLI. You write a service.json, you run flisk up (the GitHub README still says tdk up for the same package), and it generates the local Docker and Tilt wiring so those services start on your machine. Production stays on Helm. That is the whole product sentence, and it is a small sentence on purpose.

The interesting question is not whether the binary is big. It is whether the mess it refuses to own is big.

What is actually small

The contract is one manifest per service.

{
  "appName": "orders",
  "appType": "frontend",
  "port": 3001,
  "framework": "vue"
}

From that, the CLI writes the local files you usually hand-maintain: Dockerfile, nginx or Traefik routing, env files, Vite and TypeScript config, a Tiltfile. Docker runs the containers. Tilt live-updates them while you code. Flisk writes the config Tilt consumes. It does not deploy. It does not replace CI. It does not need a local cluster.

Core is MIT and needs no license key. Premium is optional, at $19 per developer per month, for extras such as a local Verdaccio registry, DDD scaffolding, and Sablier idle stop. If flisk up is all you want, you do not buy anything.

That is a small surface. A new hire can hold it in one afternoon: manifest in, local URLs out, flisk doctor instead of a setup wiki. The project itself says onboarding time has not been measured on a hiring cohort. Treat "minutes, not a wiki" as a design claim, not a benchmark.

What is actually big

The pile this sits on is not small.

A normal multi-service repo accumulates a private operating system:

Dockerfiles that drift per service
a Compose file, or five override files, that only one person can edit
nginx or Traefik routes
a Tiltfile or Skaffold config
Postgres, a queue, a local npm registry
env files, golden base images, Playwright against the running stack
an onboarding page that was true in March

Coding agents make that pile worse, not better. They are good at application code and bad at keeping Dockerfiles, Tiltfiles, and nginx configs consistent. Every invented local config burns tokens and review time. Flisk's pitch is that the agent should see a topology, not invent one.

That is the big thing. Not the CLI. The decision that local infrastructure is generated from a contract, and that production deployment stays somewhere else.

Piece	Who owns it
Business logic	You, or your agent
Local topology, routes, Dockerfiles, Tilt loop	Flisk, from `service.json`
Staging and production	Helm, Argo CD, or whatever you already trust
Agent step logic, retries, checkpoints	LangGraph, Temporal, Mastra, your own runner
Where that agent process, its DB, MCP tools, and gateway run locally	Flisk, if you want that

Flisk does not implement durable execution. It hosts it. That distinction matters. If you came looking for a workflow engine, this is the wrong drawer.

The scale numbers, without the costume

The homepage publishes boot numbers. Read them as fixture benches.

14 tiny services were healthy in 4.6 seconds on a 16 GB M1 after images already existed. Not a cold boot.
A warm restaurant example (6 services, Traefik, Postgres) took 38 to 50 seconds to 8/8 healthy on a 16 GB Apple Silicon Mac, images kept.
A cold run of that same example, caches removed, took 281 seconds.
A generated /health fixture of 100 small services, about 20 lines each, is what the "100 services" chart is. On a clean CI runner that fixture was described as healthy in about 8 minutes from scratch. Real apps with real dependencies use more memory.
Settled memory for those tiny health containers was about 1.63 GiB at 100 services, roughly 17 MiB each, with no Postgres or Traefik in that memory figure. Do not quote that as "an ERP fits in 2 GB."
The daily driver they describe is a 14-service stack on a 16 GB M1. The same engine runs a 27-service monorepo every day.

Selective startup is the feature that makes any of this usable. flisk up <stack> starts a slice. --dry-run shows what would start before a container exists. You do not boot a hundred services to change a button.

The project is small. Say that out loud.

As of 22 October 2026, the public repo is young and quiet in the way that matters for adoption risk:

TDK development started on 21 April 2026. This flisk repository was created on 19 September 2026. The npm package @flisk-sh/flisk was first published on 21 September 2026.
GitHub showed 24 stars and 33 forks.
Four teams are listed, with consent, in ADOPTERS.md: Lekast, mfin.services, MakeOffer, and Red Moon Digital.
Their own comparison doc says the community is small.
Generators are TypeScript-first. Go, Java, and Python services are bring-your-own.
Native Windows is inspect-only. Startup needs Ubuntu on WSL2.
Stability is marked 1.x local dev. Generated files are a contract you can check with flisk config verify, not a promise that the generator will never move.

A small community means you will read source and file issues. That is fine if the CLI deletes a class of YAML you hate. It is a bad bet if you need a vendor, an SLA, and a conference track.

When it is the wrong size

Docker Compose is the better tool for two or three services you already wrote. Their comparison doc says this plainly: a handful of containerized services does not need another manifest. If your Tiltfile already works, stay on Tilt. Flisk writes a Tiltfile. It is not a better Tilt.

It starts to earn its keep around a medium landscape, roughly 10 to 50 services, where one Compose file becomes a team artifact and you want flisk up payments instead of a profile flag nobody remembers. It also earns its keep when agents are about to generate the fifteenth Dockerfile.

It is the wrong tool if you want local dev to be a tiny production cluster. Skaffold, Garden, and DevSpace target a cluster. Flisk targets Docker on the laptop. If your team’s rule is "local must be Kubernetes," do not adopt this and then argue with the rule.

A ten-minute test that respects the size

Prerequisites: Node.js 22.12+, Docker Engine 25+ with Compose 2.20.2+, Tilt, and Bun 1.2+ if you use the default generated services.

npm install -g @flisk-sh/flisk
mkdir shop && cd shop
# README calls the binary tdk; the website calls it flisk.
# Run whichever `*-version` your install actually provides.
flisk project --yes
flisk resource orders-api --type backend --stack shop --yes
flisk up shop --dry-run
flisk up shop

If dry-run is already more annoying than your Compose file, stop. You learned the tool is smaller than your current workflow, which is a successful evaluation.

If dry-run shows a topology your agent can read, and up gives you health-checked URLs without a wiki, you found the big part. It was never the binary.

The size, in one line

Flisk is a small CLI for a large, boring problem: keeping a multi-service local stack generated, selective, and out of the agent's hands. The project around that CLI is still small. Believe the second sentence as much as the first.