Fleet of independent dev stacks: one project per stack, or one project with a namespace per stack?

[sg650]

Context. Local development on a single machine (macOS). We run up to ~10 independent
full-stack instances of the same app side by side — each one its own git worktree and
branch, with its own ports, Postgres database, Redis DB and Temporal namespace. Each
instance is 4–6 long-running processes (Rails, Vite, a Node BFF, a worker or two).
Instances get created and destroyed frequently, by humans and by coding agents, so a
small tool of ours provisions them and shows a cross-instance dashboard. We'd like
process-compose to own the processes — the built-in MCP server and --read-only mode are
a big part of the appeal on the agent-facing side.

Two shapes we're weighing:

A. One project per instance. N detached daemons (-D, explicit UDS path each), each
with its own process-compose.yaml committed in that instance's worktree, so the
process list is versioned with the branch it belongs to. Our tool starts/stops daemons and
fans out over the sockets for the dashboard.

B. One project total. A namespace per instance, project update to add and remove
namespaces as instances come and go, one socket for everything.

I've read #377, #378, PR #385 and your extends suggestion there, plus #319 — so I know
this is adjacent to ground already covered. Our case differs from #377 in one way that may
matter: our tool always knows the complete picture (it owns the instance registry), so
generating a full merged config for project update is straightforward for us.

Questions

1. The deciding one: on project update, what happens to processes whose config is
   unchanged — are they left running untouched, or restarted? If adding a namespace
   restarts unrelated namespaces, B is out for us, since it would bounce a colleague's (or
   another agent's) running stack.
2. Is B a shape you'd endorse for long-lived processes at all, or is project update
   aimed at smaller edits than "add/remove a whole 5-process namespace several times an
   hour"?
3. Any practical ceiling worth knowing for a single project — say ~50–80 long-running
   processes across ~10 namespaces?
4. For A, is there anything about ~10 detached daemons per user that you'd warn against?
   The default log path looks user-scoped (/tmp/process-compose-<user>.log), so I assume
   we'd need to give each daemon its own --log-file and --unix-socket to avoid
   collisions — is that the expectation, or is there a better convention?
5. Is extends the intended answer for "same 5 processes, different ports/env per
   instance", or would you generate a config per instance and skip inheritance?

Not asking for features — just trying to build with the grain of the design rather than
against it. Thanks for process-compose; it's the only thing we found that fits
non-containerized multi-stack local dev.

[goutamadwant]

On the deciding point: unchanged processes are left running. The current UpdateProject implementation compares each process config and skips equal ones; additions start, removals stop, and changed processes are replaced. That also matches the configuration-update documentation. Adding a namespace does not itself require restarting everything.

For B, two details matter:

• Process names are project-wide map keys, so use stable, instance-qualified names, not repeated rails/vite names distinguished only by namespace.
• Updates reapply the original namespace/process selection. If the daemon starts with a restricted selection, adding another namespace to its config does not automatically admit it.

Given your branch-versioned configs and independent lifecycles, I'd lean toward A. That's an architectural preference, not a maintainer endorsement or a measured capacity claim. A project-wide stop or bad aggregate update then affects one worktree instead of the fleet. Your proposed explicit per-instance socket and log paths fit the CLI; use --use-uds as well as --unix-socket to select UDS mode. The CLI reference lists those flags and the user-scoped default log path.

I can't establish a safe 50–80-process ceiling or ten-daemon overhead from this code. Before choosing, I'd test your pinned version with two stacks: record their PIDs, add/remove a third, and check both PID stability and shutdown isolation. That directly exercises the property you need, independently of whether config reuse uses extends or generation.