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 devAlternatively, 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 devBranch 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.