Your coding agent runs the whole stack.

Connect Claude Code, Cursor or Codex to Flisk, and your agent can scaffold, start, check and fix a full local app on your laptop: web, API, database and agents, without rewriting Dockerfiles.

  • free, MIT core
  • runs on your machine
  • no account
  • 21 MCP tools
terminal, in your project folder
# install the Flisk CLI
npm install -g @flisk-sh/flisk
# connect it to Claude Code
flisk connect claude

This writes .mcp.json and the Flisk skills in .claude/skills/; Claude Code asks you to approve the server once. Add --dry-run to see the files first.

# install the Flisk CLI
npm install -g @flisk-sh/flisk
# connect it to Cursor
flisk connect cursor

This writes .cursor/mcp.json and the Flisk skills in .agents/skills/, keeping any other servers in the file. Add --dry-run to see the files first.

# install the Flisk CLI
npm install -g @flisk-sh/flisk
# connect it to Codex
flisk connect codex

This writes .codex/config.toml and the Flisk skills in .agents/skills/. Codex loads a project config only for trusted projects.

# install the Flisk CLI
npm install -g @flisk-sh/flisk
# add to your client's MCP config (stdio)
{ "mcpServers": { "flisk": { "command": "flisk", "args": ["mcp"] } } }

Any agent that can run terminal commands also works without MCP: point it at the AGENTS.md that Flisk writes.

What your agent can do

Each tool runs the matching flisk command, so it behaves exactly like the CLI you would type yourself.

resource_create, project_init

Scaffold the app

Create a Flisk project, or clone a starter, then add services: a frontend, a backend, a worker, an MCP tool server or an agent, each with its own service.json, Dockerfile, source and a test.

up

Start the stack

Start everything, one stack, or only the services a task needs plus what they depend on.

status

See what is running

Stacks, services, their local URLs and ports, and whether every service is ready yet.

logs

Read the logs

A bounded snapshot of recent log lines, filtered by service and time, so the agent reads the error instead of guessing at it.

doctor

Check the machine

Whether Docker, Tilt and ports are ready before anything starts, and what to fix when they are not.

config_verify

Catch config drift

Checks that every service.json is valid and the generated files still match, and lists the diffs when they do not.

and 14 more

The rest of the toolbox

Restart one service, stop the stack, inspect agent sessions, list networks and regenerate config.

  • down
  • resource_restart
  • resource_list
  • stack_list
  • stack_assign
  • project_info
  • project_import
  • network_list
  • agent_list
  • agent_sessions
  • config_explain
  • config_regenerate
  • runtime_check
  • project_eject

How it works

Flisk is the runtime. Your agent is still the one writing code; it now has a reliable way to run it.

  1. Connect your agent

    Install the CLI and run flisk connect claude, cursor or codex. It adds the flisk mcp server and the Flisk skills; the server runs over stdio on your machine.

  2. Ask for an app

    Describe what you want in plain words. The agent creates the project and its services with Flisk, and Flisk writes the skills and AGENTS.md that teach it the rest.

  3. It runs, checks and fixes

    The agent starts the stack, polls status until it is ready, reads logs when something fails, fixes the code and checks again.

Try it with one prompt

Make an empty folder, open your agent there and paste this.

prompt
Build me a small online shop with a storefront and an orders API,
and run it on my laptop with Flisk.
  1. doctorChecks that Docker and Tilt are ready on this machine.
  2. project_initCreates the Flisk project and writes the skills and AGENTS.md.
  3. resource_createAdds the storefront and the orders API as services.
  4. upStarts the stack in the background.
  5. statusPolls until every service is ready, then gives you the local links.
  6. logsIf a service fails, reads the error, fixes the code and starts again.

The exact steps depend on your agent and your prompt. The links point to localhost, so only you can see the shop.

What it is not

Flisk does one job: run your app locally while you and your agent build it.

  • Not a deploy tool

    Nothing ships to a server. Production stays on your own pipeline, for example Helm.

  • Not Kubernetes

    Services run on Docker and Tilt on your laptop. There is no cluster to set up, and Flisk writes no cluster manifests.

  • Not a cloud IDE

    No hosted workspace and no account. Your code, containers and data stay on your machine, inside the editor or terminal you already use.

Questions

Does it cost anything, or need an account?
No. The core CLI and the MCP server are MIT licensed and need no license key and no sign-up. Premium is an optional key for team extras.
What does my machine need?
Docker (or Colima or Podman) and Tilt to run a full stack, and Node.js 22.12+ to install the CLI from npm. macOS, Linux and Ubuntu on WSL2 are supported. Ask your agent to run doctor first; it tells you what is missing.
Do I have to use MCP?
No. Any agent that can run terminal commands can use the flisk CLI directly, guided by the skills and AGENTS.md that Flisk writes into the project. MCP gives the agent typed tools and JSON results instead of parsing terminal output.
What can the agent change on my machine?
The same things the flisk commands can: project files, local containers and the local stack. Tool arguments are checked before anything runs, and nothing is deployed. Your agent host still asks before it uses a project MCP server or runs a command, depending on its settings.
Can it run AI agents as services, too?
Yes. An agent resource gets health and readiness endpoints and stored sessions that survive restarts, and the MCP tools agent_list and agent_sessions let your coding agent inspect them.

Give your agent a stack it can run

Connect Flisk to the agent you already use. Free, MIT core, on your own laptop.