dekit: a client-server process runner that keeps mprocs alive after the terminal closes

What dekit is trying to fix about mprocs

mprocs is a foreground TUI. You start it, it takes over the terminal, and when the terminal goes away the processes it was supervising go with it. That is fine for a developer watching test output. It is a poor fit for anything longer lived: a dev server you want to check from a second shell, a set of services you want to restart without losing the pane layout, or an automation script that needs to start and stop processes without a human at the keyboard.

dekit's stated answer is a client-server split, explicitly compared to tmux in the README. Processes live in a server; the TUI, the CLI and agents are clients that attach to it. The README frames this as three additions over mprocs: processes that keep running independently of the terminal and can be reconnected to, coordination of services and tasks through dependencies and readiness checks, and automation through scripts alongside interactive control.

The audience is therefore narrower than "anyone who runs multiple commands". It is people who already run several long-lived processes in one project and have outgrown a single foreground pane: backend plus worker plus queue plus a file watcher. If your workflow is one command at a time, the client-server layer is overhead you will not use.

Client-server, dependencies and readiness checks

The architecture is visible in the repository layout rather than in the README. Cargo.toml declares a workspace with `default-members = ["src"]` and a second member, `helpers/print-key`, a small binary for reading terminal keys. Rust is the implementation language, and the release profile is tuned for a small artifact: `opt-level = "z"`, `lto = true`, `panic = "abort"`, `codegen-units = 1`, and `strip = "symbols"`. That is a deliberate choice to ship a compact binary at some cost to compile time, which matters little for a tool of this size.

There is also a `schemas/` directory at the top level. Combined with the README's mention of a configuration format and a JavaScript API that are still being designed, the reasonable reading is that schemas describe the config and the scripting surface, and that they are the part most likely to move. A `config.toml` sits at the repository root, so TOML is the format in play. The `packaging/` and `scripts/` directories handle distribution and build steps; `proptest-regressions/` indicates property-based tests have already found and recorded failing cases.

The dependency and readiness-check feature is described in prose only. The README says dekit will "coordinate services and tasks through dependencies and readiness checks" but does not show the syntax, the ordering semantics, or what happens when a readiness check never passes. That is the single most interesting claim in the README and the one with the least supporting detail.

Installing dekit today is not possible, and here is what to run instead

The README is unambiguous: the first dekit release is not available yet, and published mprocs releases remain available for use. There are no install instructions for dekit itself, so any command you find elsewhere claiming to install it is not something this repository documents.

What the README does document is the compatibility path. Development builds of dekit support the mprocs CLI by prefixing it:

dekit mprocs ...

Everything after `dekit mprocs` is passed through to the mprocs command line, so existing mprocs invocations keep working. The README says this support exists in development builds and will continue after release. It does not say where those development builds are published, and the release list contains only canary and head entries tied to master plus the older v0.9.6 tag, so treat this as a documented intention rather than a download link.

If you want a working tool now, the README points to the mprocs v0.9.6 release and binaries and to README-mprocs.md for installation and usage. That file is in the repository and is the correct starting point. The screenshot in img/mprocs1.png shows the interface you would actually be using.

The release is blocked on four unfinished items

The README carries a short TODO list before the first dekit release. It is worth reading as a risk register rather than a roadmap, because each item is a thing that can change under you.

First, the CLI, config format and JavaScript API are not final. Any script written against the current design may need rewriting. Second, live upgrade is not done, which is a real gap for a server that is supposed to outlive the terminal: replacing the running server without dropping the processes it supervises is the whole point of the client-server design, and it is listed as unfinished. Third, per-project dekit versioning is unresolved, so there is no documented answer yet to what happens when two projects on one machine expect different dekit versions. Fourth, Windows has bugs and missing features, listed without detail. The repository topics include windows, so the intent is cross-platform, but the README does not claim it works there yet.

The honest summary is that dekit is a redesign in progress. The parts that are finished are the parts mprocs already had.

How dekit differs from tmux and from process supervisors

The README compares dekit to tmux, and the comparison is fair at the level of architecture: a server holds state, clients attach and detach. The difference is what the server knows. tmux holds panes and shells; it has no concept of a process being ready, no dependency ordering, and no structured view of what each pane is running. dekit's stated goal is to know that a task depends on another task and that a service is ready before starting the next one. That is closer to a process supervisor than to a terminal multiplexer.

The closer comparison is with mprocs itself. mprocs already solved the display problem: separate output per process, and interaction with each one. dekit keeps that interface and moves the process ownership out of the TUI. If you are choosing between them today, the choice is not features, it is availability. mprocs v0.9.6 is released and documented in README-mprocs.md. dekit is not released, and the README says so.

A general-purpose supervisor is the other option, and the difference is direction of control. Supervisors are configured for unattended operation and expose logs and restart policies; dekit is built around a human or an agent attaching to a running set of processes and interacting with them. If nobody needs to attach, the client-server layer buys you nothing.

Licence, maintenance and what an upgrade will cost

dekit is MIT licensed, and the LICENSE file is at the repository root. The same licence covers the mprocs code the project continues from, so moving from mprocs to dekit does not change your obligations. MIT is permissive: you can use, modify and redistribute the code, including in closed products, provided the copyright notice and permission notice are preserved. That is a description of the licence text, not legal advice, and the LICENSE file is the authority.

Maintenance is easy to state from the repository facts. The last push was on 2026-09-23, and the repository is not archived. The most recent tags are canary and head, both tied to master, with v0.9.6 from 2026-06-06 as the last numbered release. A canary tag is not a stable release, and the README confirms the first dekit release is still pending.

Upgrade cost is the part that deserves attention before you commit. The README lists live upgrade as an unfinished item, which means the mechanism for replacing a running dekit server is not settled. Combined with an unfinalized config format and JavaScript API, the practical cost of adopting dekit early is that configuration and scripts may need rewriting between versions. The `dekit mprocs ...` compatibility path is the mitigation the README offers, and it is the reason an existing mprocs setup can be carried forward without a full rewrite.

Editorial conclusion

Adopt dekit only if you are already invested in mprocs and want to track where the process runner is heading; the README states plainly that the first dekit release is not available yet, so production use is premature. Stay on mprocs v0.9.6 if you need a working tool today. Before building anything on dekit, verify three things in the repository: whether the config format and JavaScript API have been frozen, whether the Windows bugs listed in the TODO are closed, and whether the mprocs compatibility path still works through `dekit mprocs ...`.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pvolok/dekit on GitHub
4. README
5. Releases