Your Stack Has a Size. Flisk Only Fits One of Them.

"We have microservices" is not a sizing input. Twelve services in one Compose file is a different job from twelve services that each own a manifest, a route, and a health check. Flisk is opinionated about which of those jobs it wants.

This is the decision table I wish every "should we adopt this" thread started with.

Three sizes, three tools

The middle row is the product. Everything else is a way to waste a week proving a README you could have believed.

What "medium" feels like on a Tuesday

You are not booting an ERP. You are trying to change checkout without starting payroll.

Flisk's answer is stack-scoped startup. flisk up shop starts that stack. flisk up shop --dry-run prints the services and URLs and starts nothing. Ports come from the manifest. Routes land on a local domain such as http://api.shop.localhost/... when port 80 is free, otherwise on a port the CLI prints. Dev ports bind to 127.0.0.1 unless you set TDK_BIND_ADDRESS.

That is the feature. Not "100 services on a laptop."

The 100-service figure is a generated /health fixture: small stub services, all routed through Traefik, used as a boot test. The project says a 14-service stack is the daily driver on a 16 GB M1, and a 27-service monorepo runs on the same engine. Quote those. Do not quote the fixture as capacity planning.

Memory scales with what the process does. A 20-line health handler at about 17 MiB does not predict a Java API with Hibernate. If your service needs 1 GB, fifty of them do not fit because a stub bench said 1.63 GiB.

The agent test is stricter than the human test

A human can maintain a messy Compose file through folklore. An agent cannot. It will regenerate the Dockerfile, drift the Tiltfile, and "fix" nginx until the health check is a lie.

The useful Flisk behavior is drift control. You own service.json. The CLI owns .autogenerated/. flisk config verify tells you when those generated files no longer match what the CLI would write. That is a small command with a large effect: the agent has a spec, and you have a diff when the spec was ignored.

Scaffolding follows the same idea.

flisk resource bot --type agent --stack shop --yes
flisk resource tools-mcp --type mcp --stack shop --yes
flisk up shop

The agent framework still owns prompts, tool calls, and retries. Flisk owns the local process, the checkpoint volume, the MCP server route, Postgres, and the gateway. If you do not have that second problem, you do not need this CLI just because you use an agent.

A pilot that can fail in a day

Do not migrate the monorepo. Pick one stack that already hurts.

1. Run flisk doctor. If Docker or Tilt is missing, the tool is not your bottleneck.
2. Add service.json beside one existing service. Bring-your-own is a documented path. You do not have to accept the Bun/TypeScript skeleton.
3. flisk up that-stack --dry-run. Read the URL list with the person who owns the Compose file.
4. Start it. Hit /health. Change a file. Confirm Tilt updates the container instead of you rebuilding by hand.
5. Stop if the generated files fight a Dockerfile you must keep byte-for-byte. Gradual adoption exists. A rewrite disguised as a pilot does not.

Windows note, because it wastes the first hour: native Windows can inspect (version, doctor, up --dry-run). Starting the stack needs Ubuntu on WSL2.

What you should not put in the adoption slide

• "Replaces Kubernetes." It does not. Production stays on Helm.
• "Saves five hours a week." Their own site says the calculator is arithmetic on your inputs, and the five-hour starting value is an editable input, not a measurement.
• "Onboarding drops from three days to minutes." Designed for that. Not measured on a hiring cohort.
• "Runs 100 production services on a MacBook." Runs 100 health stubs in a bench. Different sentence.

The fit, in one line

Flisk is too big for a Compose file that already fits on one screen, and too small to be your platform team. It fits the stack that has outgrown one file and has not earned a local cluster.