Hey HN, Lich is a worktree aware local dev stack orchestrator. Simply put, it allows you to run multiple copies of your development stack from different worktrees with different code in parallel without going insane. I built Lich because I’ve found myself increasingly using multiple parallel coding agents for development work. I wanted my coding agents to each have independent copies of my development stack to be able to test and validate their own work well. I found that trying to do this totally broke the way I have normally setup tooling for local development. Ports conflict, the UI from one worktree connects to the backend or DB from another one, logs are hard to track down because agents start stacks in the background, any reliability problem sends agents down a rabbithole trying to fix it.

I originally built around 5k lines of bash scripts to solve this problem for a single relatively complex application was able to do it, but I realized that for any future thing I might work on I would have to build that whole setup again even though it’s not really that coupled to the specific application I’m working on. I realized I could build a clean, re-usable abstraction to solve this problem robustly and comprehensively for practically any repo through a standard lich.yaml definition and a simple CLI that manages the stack lifecycle, port allocation, log management, and garbage collection. That is what lich is.

You might wonder: why can’t I use docker compose to solve this problem? (or insert other existing tools here). The simple answer is you totally can, but it has two issues: 1. These tools really weren’t built for this use case, they might be able to support it but you’ll end up building a lot of custom tooling to make it possible. Though some tools make it easier than others. 2. If you find a tool that happens to be pretty good at solving this problem, you typically end up needing to adopt its conventions and opinions for your entire stack. Simply put, I don’t want to dockerize all of my services just to be able to run multiple copies of my stack in parallel.

Lich is intentionally designed to be un-opinionated. It sits on top of and drives whatever tooling you already have.

If you have a simple app (just a nextjs app with a development workflow that uses only a hosted testing db for example), you might find that you don’t need lich. That’s probably right. Lich is most useful when you have a relatively complex repo with multiple different services and you also want to run a copy of the DB locally. If you’re thinking about dynamically allocating ports in your startup scripts or managing state and logs, you probably need lich.

I use lich daily to run 3-5 independent stacks in parallel from different worktrees for a complex application with 5+ services and multiple docker containers per stack.

I’ve released Lich as open source with the MIT license. There’s a demo video in the GitHub readme showing me using Lich to start a dev stack in the main workspace of the lich t3 starter repo and then spawn 5 parallel subagents through Claude Code that each make an edit to the template homepage and then spawn a separate copy of the stack with it’s own DB in parallel.

The easiest way to try out lich is to use that t3 starter repo. You’ll find instructions in the GitHub readme: https://github.com/RPate97/lich