Coasts: Run 10 AI Agents Without Them Fighting Over Ports

Here's a problem nobody talks about until it hits you: you fire up two AI coding agents on the same project — say Claude Code and Codex — and they both try to spin up a dev server on port 3000. One of them crashes. The other one doesn't notice. You spend 20 minutes debugging something that isn't a bug.

Now multiply that by 5, 10, or 20 agents running in parallel. That's the reality of building with AI agents in 2026, and it's a mess.

Enter Coasts — a free, open-source CLI tool that just showed up on Hacker News and solves exactly this problem.

What Coasts Actually Does

Coasts (short for Containerized Hosts) is a CLI tool with a local observability UI. It runs multiple isolated instances of your full dev environment on a single machine. Each instance gets its own:

• Ports — no more port conflicts between agent sessions
• Volume mounts — each agent works in its own filesystem sandbox
• Network topology — isolated networking per worktree
• Secrets — encrypted secret injection per environment

The key insight: Coasts ties each isolated environment to a git worktree. If you already use worktrees (and if you're running multiple agents, you should be), Coasts just layers container isolation on top of what you're already doing.

"Coasts is agnostic to AI providers and agent harnesses. The only host requirement is Git worktrees, so you can switch tools without changing how you work."

The Multi-Agent Problem

If you're running one AI agent at a time, you don't need Coasts. But that's not how people build anymore.

The current meta (and I've written about this before) is running multiple agents in parallel. One agent handles the backend API. Another builds the frontend. A third writes tests. Maybe a fourth refactors that gnarly auth module you've been avoiding.

The problem is these agents are dumb about infrastructure. They all want port 3000. They all want to write to the same node_modules. They all think they're the only process on the machine.

Before Coasts

You manually manage ports. You run PORT=3001 npm run dev in one terminal and PORT=3002 npm run dev in another. You hope the agents don't overwrite each other's work. You pray Docker Compose doesn't choke on the third service. You babysit.

After Coasts

You write a small Coastfile at your repo root. You run coast checkout feature/auth and coast checkout feature/ui. Each worktree gets its own container, its own ports, its own world. The agents don't know about each other. They don't need to.

Works With What You Already Have

This is the part that sold me. Coasts doesn't require you to rewrite anything:

• Already use Docker Compose? Coasts boots from your existing docker-compose.yml
• Don't use Docker at all? Coasts still works — it handles the containerization for you
• Use Claude Code? There's a dedicated demo showing Coasts + Claude Code integration
• Use Codex? Same — dedicated demo video for Coasts + Codex
• Use Cursor? Covered. Conductor? Also covered.

The CLI install is one line:

eval "$(curl -fsSL https://coasts.dev/install)"

And it's built in Rust, so it's fast. The observability UI runs locally on port 31415 — you can see all your active environments, their ports, and their status at a glance.

Why Offline-First Matters

Here's what I really like about Coasts: it's completely offline-first. No hosted service. No cloud dependency. No API key to some SaaS dashboard. No vendor to go bankrupt or pivot to enterprise pricing.

Their own words: "Even if we disappeared, your local workflow would keep running."

This matters because the tools you depend on for your daily workflow should not require someone else's server to be online. Your dev environment is your problem. Coasts keeps it that way.

The Setup

Requirements are minimal:

• Rust (stable toolchain)
• Docker
• Node.js
• socat
• Git

After install, you create a Coastfile at your repo root — it's small, declarative, and tells Coasts how to spin up your environment. If you already have a docker-compose.yml, Coasts can use that directly.

Then it's just:

# Start the daemon
coast daemon start

# Check out a worktree with its own isolated environment
coast checkout feature/my-feature

# Peek at all running environments
coast status

# Open the local UI
coast ui

Current Limitations

Being honest about what's not perfect:

• macOS-first — Linux works, but canonical ports below 1024 need extra setup
• Early stage — it's a Show HN project, not a battle-tested enterprise tool
• Learning curve — if you don't already use git worktrees, there's a concept to learn first

None of these are dealbreakers. The Linux support is actively being developed, and the worktree concept is worth learning regardless of Coasts — it's how you should be working with multiple agents anyway.

The Bigger Picture

We're entering the era of multi-agent development. The tools that survive will be the ones that make it easy to run agents in parallel without infrastructure headaches. Coasts is early to this — and it's doing it right.

Open source. Offline-first. Agent-agnostic. No lock-in. Works with what you have.

That's the pattern. Tools that respect your setup and don't try to replace it.

Star it on GitHub · coasts.dev · HN Discussion