14 Sept 2026 ยท 2 min read
Parallel Govard environments for every branch
Running isolated Govard environments per feature branch so reviewers test real code, not descriptions
Part 2 of the Govard deep-dive series โ isolated environments per branch so reviewers test real code, not descriptions.
Why one shared local environment causes conflicts
A single shared local environment is a bottleneck the moment two people need it at once. Reviewer A is checking a checkout fix on feature/csp while Reviewer B needs the same machine to validate a search tweak on feature/search. Whoever wins the machine validates their own change; the other waits, or worse, both work on the same database and overwrite each other's fixtures.
The fix is isolation, not scheduling. Govard's worktree model means each branch gets its own checkout and its own container set, addressable on its own .test domain. A reviewer clicks a URL and sees the actual code on that branch โ no "trust me, it works" handoff, no reconstructed steps in a bug report. The environment becomes part of the pull request, not a separate favor someone has to do.
Spinning up an environment per branch
Start from a clean worktree for the branch, then bring its stack up. Because each environment is isolated, the domain and data are unique to that branch:
git worktree add ../example-store-feature-csp -b feature/csp
cd ../example-store-feature-csp
govard env up
# reachable at https://example-store-feature-csp.test
For pull-request previews, the same pattern runs in CI: a runner creates the worktree, runs govard env up, and exposes the .test URL to the reviewer. The base branch is never touched, so a failing preview never destabilizes local daily work.
Switching between environments is just a matter of which one is running. List them, bring one down, bring another up:
govard env ps --all # list every Govard environment on the host
govard env down # stop the current worktree's stack
govard env up # start another branch's stack
When the branch is merged or discarded, tear the environment down so its volumes and ports are released:
govard env down --volumes # remove containers AND their data volumes
git worktree remove ../example-store-feature-csp
Pitfalls
- Volume or port collisions. Two environments that are not properly isolated can fight over a port or mount the same database volume. Always scope each env to its own worktree and verify with
govard env ps --all. - Forgetting cleanup. Preview environments pile up after a busy sprint; a weekly sweep of stopped worktrees keeps disk and port ranges free.
- Database drift between environments. If two branches were seeded from the same remote at different times, their data diverges. Re-sync from a known remote before comparing behavior, rather than assuming parity.
Next in this series: Debugging inside Govard: Xdebug, logs, and introspection โ /blog/govard-debugging-tooling