An AI-native development environment
Claude sessions, service logs, distributed traces, and crash reports — all scoped to the worktree you're working in. Investigations become Cases, committed to git alongside the fix. One keyboard-driven interface instead of a collection of disconnected tools.
How a Fix Happens
Something breaks in production. You open a Claude session, and it can pull logs from your remote hosts, run distributed traces across services, and read crash reports directly—so the investigation starts from real data. You find the root cause, write the fix, and save the whole investigation as a Case—notes, the Claude transcript, the trace report—committed alongside the diff.
Or you're building a feature. Your local services are running, Trellis restarts them as you rebuild, and you're working through the implementation in a Claude session. When you're done, you capture the design notes and Claude transcript as a Case, so the reasoning lives in the repo with the code.
What Trellis Does
On Your Machine
- Worktrees as environments — Each git worktree gets its own terminals, processes, and logs
- VSCode integration — Open VSCode scoped to the worktree you're viewing with a single keystroke
- Terminal & tmux management — Trellis creates and manages tmux sessions for you
- Service supervision — Run your app's components locally with automatic restart on rebuild
- AI sessions — Claude Code or Codex chat scoped to each worktree, with access to your services, logs, crashes, and CLI tools
- Pair review & checklist runs — Two AI sessions review each other's work automatically, or work through a multi-phase checklist one reviewed phase at a time
- Session inbox — A floating popup listing every live AI session across worktrees, highlighting the one waiting on you
- Usage & cost tracking — Today's agent spend in every page header, with daily, per-worktree, and per-session breakdowns
- Cases — Capture work as a committed case directory (notes, evidence, Claude transcripts; traces when relevant)
- Local log access — Tail and search logs from the Trellis UI
Remote Systems
- Remote terminals — SSH into staging or production from the same interface
- Tailing remote logs — Stream logs from remote hosts in real time
- Grepping remote logs — Search through remote logs, including rotated and compressed files
- Distributed tracing — Search for an ID across multiple machines at once
- Claude + production context — Claude sessions can query remote logs, run distributed traces, and read crash reports directly, so debugging starts from real data instead of guesswork
Navigation & Speed
- Web UI, keyboard-first — Runs on localhost but designed for keyboard operation
- Unified picker — One searchable dropdown (
Cmd+P) to jump between worktrees, terminals, services, log viewers, Claude sessions, and cases - Keyboard shortcuts — Common actions bound to shortcuts so you rarely touch the mouse
Why Trellis Exists
I built Trellis because the tools I was using to develop Groups.io were annoying me.
Groups.io isn't a weekend project. It's been running for over a decade, has millions of users, and a lot of moving parts. I write the code, run the dev environment, deploy to production, and get woken up when something breaks. The neat "dev vs ops" distinction doesn't really apply—it's just me switching hats all day.
For years, I glued things together with shell scripts, tmux sessions, and manual steps. It worked, but it was fragile. I'd switch branches, start the services I needed, dig through logs, SSH into production, then jump back to local code. The context lived in my head, and if I lost track, I paid for it.
I wanted a single workflow—from "I'm writing this code" to "what just broke in production." So I built Trellis.
Trellis isn't a provisioning system and it doesn't replace your cloud or orchestrator. It becomes your dev environment. It runs your services, restarts them when binaries change, scopes terminals and logs to what you're working on, and keeps everything in sync with the active branch. Switch worktrees, switch your world—without leaving behind a mess of sessions and state.
I built Trellis for myself. After a while, I realized other people were solving the same problems. So here it is.
Who Trellis Is For
Trellis is for:
AI-assisted development
Trellis gives Claude Code a native interface with direct access to your services, logs, and traces. Investigations happen inside the same environment your code runs in—not in a separate chat window with copy-pasted context.
Developers who also operate their systems
If you write code and are responsible for keeping it running, Trellis gives you one place to develop, debug, and inspect live systems without switching tools or losing context.
Founder-operators and small teams
Trellis fits teams where deep system knowledge matters more than heavy process, and where the same people build, deploy, and debug production.
Infra-heavy codebases
Services that run continuously, depend on each other, and fail in interesting ways benefit most from Trellis's service lifecycle management and log-driven introspection.
Parallel development workflows
If you use git worktrees or juggle multiple branches at once, Trellis treats each as a first-class environment with isolated services, logs, and workflows.
Trellis is not for:
Teams looking for a hosted dev platform
Trellis does not provision environments, manage cloud resources, or replace Codespaces-style workflows.
Production automation or SRE platforms
Trellis does not deploy, scale, or mutate production systems automatically.
Highly abstracted "no-ops" workflows
If you don't want to see logs, processes, or terminals, Trellis will feel too hands-on.