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 (6)
The part about reviewing the wrong version without knowing it hit way too close to home. I have spent more time than I care to admit staring at a "working" feature, only to realize the browser was still connected to an old process that somehow survived three restarts. At that point, you start questioning not just your tooling but your entire perception of reality.
Agent-Up feels like the missing piece that makes parallel agent workflows actually manageable. The worktree approach was always half the story—it isolates source code but completely ignores the runtime, and that is where the real chaos lives. Giving each agent its own ports, Docker services, and browser session is the kind of obvious-in-hindsight solution that makes you wonder why nobody built it sooner.
One thing I would love to see, and maybe you already have this planned, is a small visual indicator in the browser tab or the app itself that clearly shows which workspace is currently active. Something like a color-coded badge or a workspace name in the title bar. When I am juggling five agent workspaces, I need to know at a glance which one I am looking at without digging through logs or checking port numbers.
Also, since you already have the MCP server handling environment injection, I wonder if you have considered adding a lightweight "review mode" that captures a snapshot of the workspace state—ports, running processes, browser tabs, logs—and exports it as a report. That way, when an agent finishes a task, you get a bundle you can share with a teammate or attach to a PR without them having to spin up the same environment themselves. It feels like a natural extension of the isolation philosophy.
Anyway, this is genuinely useful work. Dropped a star on the repo and looking forward to seeing how the project evolves. Thanks for sharing it with the community.
Thanks, and thanks for the star!
I know that “wrong version” moment all too well 😂
That confusion is a big part of why I started building Agent-Up.
The active workspace indicator already exists in the desktop app. The selected workspace is highlighted in the workspace list, and its associated tabs, ports, console output, and browser session are shown together. I agree that this context has to be obvious at a glance.
The export idea is interesting. The closest planned feature right now is Playwright flow export, where reviewed browser interactions could be turned into a reproducible test.
A reproducible action-chain export would be great for sharing review problems with teammates, I agree! I am adding that broader review snapshot/report idea to the roadmap too. Thanks for the thoughtful feedback.
Glad to hear the workspace indicator is already in place—and that you've also experienced the existential dread of debugging a feature that was "working" on a zombie process from three restarts ago. At this point, I half‑expect to find old processes living in my walls like friendly ghosts that occasionally serve stale responses.
On the export idea, I think the Playwright flow export is a great direction, but I would also suggest a lightweight workspace manifest that captures not just browser interactions but the entire runtime context: environment variables, active ports, Docker container IDs, and the exact commit hash of the code running in each service. That way, when you share a snapshot with a teammate, they can spin up the exact same state without having to guess which version of which microservice was running. It could be as simple as a workspace-snapshot.json file that the MCP server writes on demand, with references to the Docker images and the Git refs.
One more thought: if the snapshot includes logs from the relevant time window (say, the last 5 minutes before the snapshot), it becomes a self‑contained debugging package. I have spent way too many hours trying to reproduce a bug only to realize the logs I needed were overwritten by the next agent's run. A snapshot with logs attached would save that pain.
Also, for the PR integration, you could let the MCP server attach the snapshot as a comment or a file in the PR, so reviewers can click a link and open the exact workspace state in Agent‑Up without any manual setup. That would make the handoff from agent to reviewer completely seamless.
One technical question: how do you currently handle versioning of the workspace state across multiple agent runs? Do you keep a history of snapshots, or is it just the latest state? I could see value in a lightweight timeline view that shows how the workspace evolved across agent iterations—like a Git log for runtime states.
Anyway, I'm excited to see where this goes. The roadmap sounds solid, and I will be keeping an eye on the repo for the export features. Thanks again for building something that finally makes parallel agent workflows feel sane.
The development flow is Git-based. Each agent works in its own Git worktree and on its own branch, while Agent-Up manages the separate runtime environment around that worktree: its processes, ports, Docker services, browser session, tabs, logs, and current runtime state.
The workspaces run side by side, but Agent-Up does not currently version their runtime state across agent runs. Source history and versioning remain in Git through branches, commits, pull requests, and merges. Agent-Up currently tracks the live state of each registered workspace rather than keeping a history of exported snapshots.
Your snapshot idea is very close to something I have been considering as a review capsule.
The planned Playwright export could become one part of that capsule: a fully recorded review flow covering all applications, browser views, and consoles in sync. A reviewer could open it directly from a PR, scrub backward and forward, pause, resume, and inspect exactly what happened without running the application at all.
Alongside that recording, the capsule could also contain the runnable state itself: the exact source, Agent-Up configuration, required (securely managed) secrets, and a pinned Nix flake describing the runtimes and external requirements. Importing that bundle into Agent-Up would make it behave like a normal application workspace, so the reviewer could reproduce and interact with the same version rather than only watching the recording.
The recording and the runnable workspace would be grouped together inside Agent-Up for review:
That capsule could then be attached to a PR and imported directly into Agent-Up. Reviewers could either inspect the prerecorded flow immediately or launch the bundled workspace and continue from the same version themselves.
The capsule would support the existing Git workflow rather than replace it. The agent would still work in its normal worktree and branch, and the PR would still remain the contribution and versioning mechanism. The capsule would provide the reviewable recording and the reproducible runtime handoff associated with that exact version.
A lightweight timeline across agent iterations would make sense once these artifacts exist. Each capsule could represent a review checkpoint tied back to the relevant workspace, branch, commit, and PR.
I hope this clarifies the direction I have in mind for Agent-Up.
Thanks for the detailed suggestion. It pushes the Playwright export toward something substantially more useful than a standalone recording.
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?
Not yet, but that is a great idea!
Agent-Up currently tracks workspace state, processes, and logs, and accepts MCP-driven workspace up/down actions, but it does not yet produce a complete audit chain tying together restarts, health checks, process transitions, source revisions, and browser activity. Diagnostic metrics and health checks were already planned, but I do like the audit idea!
A structured execution history would be valuable for both agents and humans, especially for understanding what happened across the last few reloads.
I am adding this to the roadmap. Thank you for that suggestion!