Lich, start a dev stack per coding agent in parallel
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…
What it does
In the maker’s words, at launch
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
Does the same job
all alternatives →
More ai this month
the category →
I trained a 125M-parameter transformer to autocomplete piano performances in real time (~108 notes/sec on an iPhone 15). The idea is basically GitHub Copilot or Tabnine, except instead of prompting it with code, you prompt it by playing a few notes on a MIDI piano. The model then continues what you played, entirely on-device. The app is free if anyone wants to try it. Happy to answer questions about the model, training, Core ML, or the many things that didn't work.
AI · 16d ago · simedw.com
Astute▲585Automate your B2B brand going viral, with new media creators
AI · 18d ago · company-app.joinastute.com
Hey HN, Henry from Cactus here! We previously released Cactus Needle, a 14MB agentic LLM for tool call, device use, and structured extraction for phones, wearables, smart homes, small robots and microcontrollers. We got really great feedback here, and have now incorporated the suggestions to release Needle 2. The whole model is a single 14MB binary that runs a full session in 28MB of RAM; 45m parameters at 2bit compression. Needle hits 500 tokens/sec decode speed on a Raspberry Pi 5, sits between 400-1,500 tokens/sec on VR devices like Meta Quest 3S and Apple Vision Pro, and ranges…
AI · 26d ago · cactuscompute.com
Launched alongside, June 2026
the whole month →
Fundraisly▲1,544AI fundraising agent that finds investors and books meetings
AI · Jun 2026 · fundraisly.com
- H6Homebrew 6.0.0▲1,481
Today, I’m proud to announce Homebrew 6.0.0. The most significant changes since 5.1.0 are a new tap trust security mechanism, the new faster, smaller, default internal Homebrew JSON API, sandboxing on Linux, better defaults informed by our user survey, many brew bundle improvements, improved performance and initial support for macOS 27 (Golden Gate). Happy to discuss any questions here!
Dev tools · Jun 2026 · brew.sh
- PU
hope you enjoy
Life & fun · Jun 2026 · vorpus.github.io
- IM
Life & fun · Jun 2026 · hackernewstrends.com