u/vladimirlobas

I posted Kranz here as a TUI for local development services and logs. Since then, I've added CLI commands and MCP access to the running services.

The setup I had in mind when I started Kranz is now working. You can start services in the dashboard, detach and manage them from the shell, or give a coding agent access through MCP. All three use the same running services.

The GIF shows this with a small demo project:

kranz status
kranz plan api --operation restart
kranz restart api
kranz runs api --limit 2
kranz logs api --run -1 --tail 3
kranz actions run api/test --param suite=smoke

Here, restarting api also restarts web and worker. plan shows that before you do it. Each service run has separate saved logs, so you can check what happened before a restart. --run -1 selects the latest run.

The last command runs a test action configured in this demo. It accepts a suite parameter, which Kranz checks against the allowed values.

At the end of the GIF, an MCP client reads the service status, API logs, and test result. A coding agent can access those too. These are just a few of the CLI commands. You can also check configs, inspect dependency graphs and ports, get JSON output for scripts, and more.

Recorded on v0.16.4 with demo services.

If you try it on your dev stack, I'd like to know which commands or output feel awkward. If it looks useful to you, I'd also appreciate a star on GitHub.

As in the first post: coding agents wrote most of the Go code. I designed the behavior and UI and tested the result.

GitHub
Docs

It has been a while since I first posted Kranz here. The first version was mostly a TUI for starting local services, checking their health, finding their ports, and reading separate logs.

Since then, continued use on real projects has expanded the tool while preserving the same core model: keeping local development processes in one place.

If a project already has a Procfile or Procfile.dev, open its directory and run:

kranz

There is no need to create kranz.yaml just to try it.

Since the first post, Kranz has added:

• a complete CLI for scripts and quick checks;
• numbered history for service and action runs;
• logs scoped to an exact run;
• project actions for migrations, builds, tests, and similar commands;
• switching between running projects without leaving the TUI;
• a draft-based kranz init wizard that shows the YAML diff before writing;
• a built-in MCP server for coding agents.

The MCP integration allows an agent to connect to a runtime already open in Kranz, inspect the same services, and read the same logs. The agent does not need a new terminal or a second copy of the stack.

The GIF uses the real v0.14.0 binary and fictional projects. It shows the Procfile start, actions, CLI, run history, MCP beside the live TUI, and project switching.

Install with Homebrew:

brew install kranz-org/tap/kranz

Or with Go:

go install github.com/kranz-org/kranz/cmd/kranz@latest

Kranz is not meant to replace Docker Compose. It runs applications under active development on the host alongside containerized infrastructure.

If you run several local services, what still feels awkward in the TUI or in the setup?

GitHub: https://github.com/kranz-org/kranz
Docs: https://kranz-org.github.io/kranz/

Some projects need several services running during local development. I usually end up with terminal tabs, tmux sessions, and a few shell scripts. That works. Finding and stopping a process that occupies a port is not hard either. I just wanted to have all of it in one place.

So I made Kranz. It can:

• start and stop services in dependency order
• show status, dependencies, ports, and health checks
• identify the process using a configured port and stop it after confirmation
• follow logs separately for each service
• restart failed services with configurable backoff
• load its own YAML config or a supported subset of process-compose.yaml

The GIF shows the real binary running a fictional five-service project.

Install with Homebrew:

brew install kranz-org/tap/kranz

Or with Go:

go install github.com/kranz-org/kranz/cmd/kranz@latest

Kranz is not meant to replace Docker Compose. Process Compose is more mature and has more options. Kranz does less on purpose. It is focused on this interactive local-development workflow.

To be honest, I do not write Go. Coding agents produced most of the implementation. I defined the behavior, UX, and constraints. I tested the tool and kept reworking the parts that did not feel right.

The project is still early. If you try it on a real project, I would like to know where the configuration or workflow feels awkward.

GitHub: https://github.com/kranz-org/kranz