Agent-Up is an open-source, cross-platform desktop app for running and reviewing multiple AI coding agent workspaces on the same machine. It is built specifically for web application development, where each agent needs more than just an isolated source tree — it needs an isolated runtime.
Every agent workspace in Agent-Up gets its own processes, stable ports, isolated Docker services, a dedicated browser session, grouped browser tabs, and its own logs and runtime state. Agents manage their environments through MCP. You review them all in one place.
The problem
Git worktrees solve source code isolation well. When you give each agent its own worktree, their changes stay separate and can be reviewed independently. But worktrees do not isolate running applications.
When several agents work on the same web app simultaneously, each may need to run a different version of the full stack at the same time. Without additional tooling, that quickly becomes unreliable:
- Ports collide between workspaces
- Old processes keep serving previous versions after an agent restarts its stack
- Browser tabs point to the wrong workspace
- Related frontend and backend tabs are not grouped together
- Docker services conflict across workspaces
- Authentication and browser state leak between sessions
The worst failure is the subtle one. An agent changes the code successfully and restarts its server — but your browser is still connected to a different agent's process. You are reviewing the wrong version and do not know it.
What Agent-Up changes
Agent-Up treats each workspace as a complete, isolated runtime environment rather than just a directory.
A workspace represents the entire monorepo: multiple web apps, APIs, workers, databases, queues, and Docker services. Each workspace gets stable, pre-allocated ports and its own browser session inside the desktop app. Its web applications appear as a dedicated group of browser tabs. Switching workspaces means switching the complete environment managed by that agent.
You always know which workspace you are reviewing, which frontend and backend versions are running, which browser tabs belong together, and which logs and processes belong to that workspace.
Multiple agents can therefore run different versions of the same full-stack web app simultaneously on one machine, without any of their environments interfering with each other.
How agents use it
An agent finishes its work and starts the new version through the Agent-Up MCP server. The server handles the rest: starting or restarting the required applications, spinning up declared Docker services, allocating conflict-free ports, injecting those ports into each process as environment variables, tracking logs and process state, and exposing the running web apps as browser tabs in the desktop app.
The entire stack does not need to be Dockerized. For many web applications, process and port isolation is already enough to run several versions concurrently without conflict.
One desktop app for all agent workspaces
Stop managing multiple terminals, port assignments, Docker stacks, browser windows, and browser profiles to keep parallel agent work straight.
Agent-Up gives each agent an isolated full-stack environment and puts the controls for all of them in a single desktop app. You can finally stop wondering whether you are looking at the correct version of your app.
Windows and macOS installers are available at agent-up.themassiveone.net.
Agent-Up is open source — view the code, report issues, or contribute at github.com/agent-up-oss/agent-up.
Top comments (1)
Isolating the source tree without isolating ports, browser state, and runtime processes is exactly how multi-agent demos turn into false reviews. The subtle bug you called out, where the code changed in one workspace but the browser is still pointed at another process, is worse than a crash because it manufactures confidence.
I like that you treated browser sessions and logs as part of the workspace contract, not an afterthought. Curious whether Agent-Up also gives each workspace a traceable execution receipt for restarts, health checks, and MCP actions, because that is usually the next missing layer once parallel agent runs become normal?