Kranz

Lifecycle, not terminal tabs

Dependency-aware start and reverse-order stop for local processes and detached external resources.

State you can trust

Separate readiness, liveness, lifecycle status, runtime port discovery, and explicit unknown state.

Operations beside services

Run migrations, builds, checks, and project actions with captured output, timeout, and confirmation.

Bring your existing config

Start with a Procfile, a supported Process Compose file, or native Kranz YAML when you need the full model.

Kranz in one minute

Your project probably has a web app, an API, a worker, a database, and a few commands you run by hand. Kranz turns those pieces into one local workspace:

open Kranz in the project directory;

select the service you need;

press s;

watch dependencies start in order and logs arrive in one place;

press s again to stop, with confirmation.

Kranz runs in the foreground. It is not a container runtime, a deployment platform, or a daemon that keeps changing your machine after you leave.

New here?

Start with What is Kranz?, then follow the five-minute quickstart. No YAML is required.

Pick the path that matches your project

You already have	Start here
A whole product and want to see everything at once	MoonFlight showcase
A few shell commands	Procfile quickstart
Services with dependencies and health checks	Native YAML example
A `process-compose.yaml`	Process Compose example
Docker Compose or remote infrastructure	Detached lifecycle example
A larger API/worker graph	Full-stack example
Migrations or setup that must run first	Prerequisites example
Processes that choose ports at runtime	Runtime-port laboratory

You already have

Start here

A whole product and want to see everything at once

MoonFlight showcase

A few shell commands

Procfile quickstart

Services with dependencies and health checks

Native YAML example

A process-compose.yaml

Process Compose example

Docker Compose or remote infrastructure

Detached lifecycle example

A larger API/worker graph

Full-stack example

Migrations or setup that must run first

Prerequisites example

Processes that choose ports at runtime

Runtime-port laboratory

What Kranz keeps together

Services are long-running things such as an API, Vite server, or worker.

Dependencies describe what must start first and when it is actually ready.

Actions are one-shot jobs such as lint, test, build, migrate, or inspect.

Health checks distinguish “the process exists” from “the service is ready.”

Detached lifecycle lets Kranz operate external resources without owning their PID, while an optional status probe reconnects state across sessions.

See the core concepts for a picture of how these pieces fit together, or jump directly to the runnable examples.

KranzYour local services, under control