Guides

Silo intercepts syscalls inside the session. Things outside the session - browsers, GUI database clients, other tools - need to reach the right IP on their own. These patterns help.

Parallel AI coding

Tools like vibe-kanban spawn multiple AI agents that each work on a separate branch. Every agent needs its own dev server - on the same port.

Wrap the dev command with silo and each agent gets an isolated loopback IP. No port conflicts, no configuration:

agent-1 (feature-auth)  $ silo npm run dev   # 127.0.1.1:3000
agent-2 (feature-cart)  $ silo npm run dev   # 127.0.1.2:3000
agent-3 (fix-header)    $ silo npm run dev   # 127.0.1.3:3000

Silo pairs naturally with any tool that creates worktrees for parallel development - AI-driven or otherwise.

Multi-service

Child processes inherit the silo session. Wrap your process manager and every service shares the same isolated IP:

silo make dev             # Makefile
silo just dev             # Justfile
silo overmind start       # Procfile
silo turbo run dev        # Turborepo

Browser access

Your dev server binds to 127.x.x.x:3000, not 127.0.0.1:3000. The browser is outside silo, so localhost:3000 won't reach it.

Use the hostname that silo adds to /etc/hosts:

$ silo ip
127.185.176.25  feature-auth.my-app.silo

# open in browser:
http://feature-auth.my-app.silo:3000

Client-side API URLs

Browser code runs outside silo, so localhost in the browser resolves to 127.0.0.1, not your silo IP.

Use the SILO_HOST environment variable to point client-side API URLs at the right address:

NEXT_PUBLIC_API_URL="http://${SILO_HOST}:8080" next dev
VITE_API_URL="http://${SILO_HOST}:8080" vite dev

Alternatively, use your framework's dev server proxy. The dev server runs inside silo, so its outbound requests are intercepted automatically.

Database isolation

Multiple worktrees often share a single database server. Migrations on one branch can break another. Silo doesn't intercept connections to external databases, but SILO_NAME gives you a stable, per-branch identifier you can use to separate them.

Database per branch

Use SILO_NAME as a suffix in your connection string:

# dev.sh
export DATABASE_URL="postgres://localhost:5432/myapp_${SILO_NAME}"
silo npm run dev

Branch main connects to myapp_main, branch feature-auth to myapp_feature-auth. Migrations stay isolated.

Database server per branch

If you run a local database per worktree, silo handles the port conflict:

silo postgres -p 5432 -D ./data &
silo npm run dev

Both processes share the same session IP. Your app connects to localhost:5432 and silo routes it to the right instance.

Shared database

If branches don't touch the schema, sharing is fine. No changes needed - your app connects to the real database address as usual, and silo only rewrites loopback addresses.

GUI database clients & other tools

Tools like TablePlus, pgAdmin, or Postman run outside silo. To connect to a silo'd service, use the session IP or hostname directly:

$ silo ip
127.185.176.25  feature-auth.my-app.silo

# In TablePlus:
Host: 127.185.176.25  (or feature-auth.my-app.silo)
Port: 5432

silo ls shows all active sessions and their ports.