Orkesy

#Why I built this

When I’m working on a project locally I usually have 3 or 4 things running at once. An API, a worker, a frontend, sometimes a database. I always end up with too many terminal tabs and a tmux config I never finish setting up properly. Logs get lost in scrollback I can’t find again.

I tried supervisord but the log viewing isn’t great. Lazydocker is nice but only really works if everything is already in Docker. I just wanted something that runs the things in my config file and shows me their output without much fuss.

#What it does

It runs anything you put in a TOML file. Node, Rust, Python, Docker Compose, shell scripts. As long as it has a start command and prints to stdout, it shows up.

The main features:

• Real-time logs with timestamps. You can pause, search, or filter by level.
• CPU, memory, and uptime per service.
• A command palette that opens with /. Same as VS Code.
• Start, stop, restart, kill from the UI. Optional auto-restart on crash.
• Three types of health check: HTTP, TCP, or run a script.
• A dependency graph view.
• It looks at your repo to figure out what kind of project it is (Node, Rust, Docker, Make, Just) and writes a starter config for you.

#Architecture

It’s one binary. There are two main parts running in parallel: a supervisor that spawns and watches the services, and a TUI that reads their output. They talk to each other through a channel so neither blocks the other.

Each service has its own log buffer with a fixed size. If one service is dumping logs faster than the others, it can’t push the rest out of view.

#Technical decisions

Rust. Mostly because of ratatui. The library is mature and the docs are good. Tokio’s channels also worked well for the supervisor / UI split. Go would have been fine too.

Per-service log buffers. Each service gets its own bounded buffer instead of one global one. If a worker is spamming logs you don’t lose your API output.

Three kinds of health check. HTTP for normal web services, TCP for databases and queues, exec for anything that doesn’t fit those. One isn’t enough.

No daemon. Orkesy starts when you run it and exits when you quit. The TOML file is the only state. Nothing in the background to maintain.

Auto-detection is just a starting point. If you have a Cargo.toml, package.json, or docker-compose.yml, it generates a starter config. After that you edit the file yourself. Nothing happens at runtime.

[service.api]
command = "cargo run --bin api"
cwd = "./crates/api"
env = { RUST_LOG = "info" }
healthcheck = { http = "http://localhost:8080/healthz" }
restart = "on-failure"

[service.worker]
command = "cargo run --bin worker"
cwd = "./crates/worker"
depends_on = ["api"]

[service.db]
command = "docker compose up postgres"
cwd = "."
healthcheck = { tcp = "localhost:5432" }

#What I learned

I kept catching myself trying to make it look like VS Code. Terminal apps work better when they stop trying to be a graphical editor.

Most of the actual time went into backpressure. The whole point is that one noisy service shouldn’t slow everything else down, and that doesn’t happen for free.

A config file is much easier to come back to than a long list of CLI flags. I forget the flags. I don’t forget what’s in a file I’ve edited.

Once the command palette was working I stopped using the mouse for most things.

#Next steps

• Persist log buffers between sessions so you don’t lose them on quit.
• Pull metrics from services that already expose Prometheus or OpenTelemetry endpoints, instead of only CPU and memory.
• A remote mode so you can manage services on a dev VM the same way.
• A plugin API so people can add detection for things like Bun or Deno without me having to add it.

Source and the latest releases are on GitHub.