Feature request: DB-optional mode — use port + env isolation without a local Postgres (for parallel multi-agent worktrees)

[luda-dvc]

Context

First — thank you for wt. The slot → port-offset → per-worktree .env model is exactly the right abstraction, and the --json support + shipped /wt skill + "Setup Guide for LLM Agents" show you're already thinking about automated workflows.

Our use case is parallel multi-agent development: many concurrent git worktrees, each driven by an independent automated coding agent, all needing non-colliding ports and self-consistent .env files. wt is the closest thing to a purpose-built solution we've found — but a hard dependency on local Postgres blocks us from adopting it.

Where it hurts today (the pains wt would solve — if it didn't require Postgres)

A typical worktree here runs several co-operating services — a web frontend, a couple of API servers, and a background worker — against a cloud-hosted database. The concrete failures when spinning up a new worktree:

1. A fresh worktree can't even boot. Our env files are git-ignored (they hold secrets), so a newly-added worktree has no .env at all. Someone has to hand-copy secrets into every new tree before anything runs. wt's env-seeding is exactly the fix — but it's unreachable without the DB step.
2. Every worktree defaults to identical ports (e.g. 3000 / 8000 / 8080), so only one full stack can run at a time. That directly caps parallel-agent work: agent B can't start its stack while agent A's is up.
3. Multi-service cross-wiring breaks on offset. When ports shift per slot, each service's URL to the others must shift too — e.g. the web app's API_BASE_URL has to point at the offset backend port, or the stack comes up half-dead (frontend loads, every call 404s). We think your existing port / url patch types already cover this; a confirming example in the docs would help.
4. A shared cloud DB has no per-slot separation. Because our database is cloud-hosted, the local-Postgres templating doesn't apply, so every worktree points at the same database — and parallel data-mutating agents then interleave writes in one place. Some form of per-slot logical separation (see the connection-string ask below) would let us fan agents out safely.
5. Slot assignment races under fan-out. When an orchestrator spawns several worktrees at once, two agents can be handed the same slot → same ports → collision (see the concurrency ask below).

None of pains 1–3 need Postgres at all — they're pure port + env-seeding wins that we simply can't unlock because DB creation is mandatory.

The adoption blocker

wt's isolation is anchored on a local Postgres (CREATE DATABASE ... TEMPLATE), and there's no documented way to skip it. Teams whose database is cloud-hosted or managed (RDS, Neon, Supabase, Atlas, PlanetScale, …) or simply not Postgres can't provision per-slot databases this way, and because DB creation is mandatory in wt new, the two features we'd benefit from most — port offsetting and .env seeding — become unreachable even though neither needs Postgres.

Primary request — a DB-optional mode

A way to run wt for ports + env only, with database provisioning turned off:

• a flag, e.g. wt new --no-db, and/or
• a config switch, e.g. "database": false / "databaseMode": "none" in wt.config.json.

This would be the create-side complement to the --keep-db flag you already support on removal, and it directly fixes pains 1–3 for every stack whose DB lives outside the local machine.

For pain 4 — a per-slot connection-string DB-name rewrite

Independent of whether wt creates the database, a patch that rewrites the DB name inside a connection string per slot (e.g. append _wt{slot} → app_wt3) would give logical isolation on a shared/cloud cluster where databases are pre-created or cheap to create out-of-band. Effectively: decouple "point this worktree at its own DB name" from "run CREATE DATABASE locally."

Optional, deeper — a pluggable provisioner

If you'd rather keep real DB isolation available to non-Postgres/cloud users than drop it, a hook-based provisioner would do it: let wt.config.json specify a user command that receives the slot + resolved DB name (e.g. provisionHook / removeHook), instead of hardcoding CREATE DATABASE ... TEMPLATE. Postgres stays the built-in default; everyone else supplies their own.

Two smaller asks for parallel-agent orchestration

Building on the agent support you already have:

1. Concurrency-safe slot allocation (pain 5). When an orchestrator fans out several wt new calls at once, allocation needs to be race-free (atomic / file-lock) so two agents never receive the same slot. Is this guaranteed today? If so, documenting it would be enough.
2. A stability guarantee for the --json schema of new / list — ideally including the resolved port map per slot — so an orchestrator can depend on it to map slot → ports → path programmatically.

Offer

Happy to contribute a PR for the DB-optional mode (and the connection-string rewrite) if that direction is welcome — just let us know the shape you'd accept. Thanks again for the tool.