Running multiple instances of the same source code in parallel is increasingly common \u2014 especially with agentic development. Tools like VS Code Copilot’s background agent create git worktrees to work on your code independently, AI agents spin up separate environments to test different approaches, and developers use multiple checkouts to work across feature branches simultaneously.<\/p>\n
This creates a fundamental problem: applications bind to specific ports, and two instances of the same app fight over the same ones. The second instance fails with a port conflict. You’re stuck manually reassigning ports, juggling environment variables, or shutting things down to switch contexts.<\/p>\n
Aspire 13.2 solves this with isolated mode<\/strong> \u2014 a new By default, Aspire runs services on predictable ports. When you start an AppHost:<\/p>\n It binds to specific ports defined in your dashboard config. If you have two instances of an Aspire project open and try to run both, the second one fails:<\/p>\n This blocks common development scenarios:<\/p>\n The workaround was tedious: manually reassign ports, manage environment variables, or restart everything to switch projects.<\/p>\n Aspire 13.2 introduces the Run it:<\/p>\n That’s it. No manual port configuration. No environment variable juggling. Each run gets a fresh, collision-free environment.<\/p>\n You’ve cloned the same repo into two directories \u2014 maybe one for a feature branch and another for a bug fix. Start the AppHost from the first checkout:<\/p>\n In another terminal, start the same AppHost from the second checkout:<\/p>\n Both run without conflicts. Each gets randomized ports. The dashboard still shows you what’s running and where, but you’re not fighting over the same ports.<\/p>\n When you use Copilot Chat’s background agent<\/strong> in VS Code, it automatically creates a git worktree in a separate directory so it can work on your code without interfering with your current session. If your project includes an Aspire AppHost, the agent may need to run it \u2014 but you’re already running the same AppHost in your primary worktree. Without isolated mode, this causes a port collision.<\/p>\n With Each gets its own ports and secrets. You keep developing while the agent builds, tests, and iterates \u2014 all against the same AppHost, without conflicts.<\/p>\n The Aspire skill that’s set up with When you pass Instead of binding to the predictable ports defined in your AppHost configuration, isolated mode selects random available ports for both the dashboard and all service endpoints. Where a normal run might bind services to ports 8080, 8081, and 8082, one isolated run might get 15234, 15235, and 15236 while another gets 22891, 22892, and 22893.<\/p>\n The dashboard and service discovery automatically adjust \u2014 your code doesn’t need changes. Aspire’s service discovery resolves endpoints at runtime, so services find each other regardless of which ports they land on.<\/p>\n Each isolated run gets its own user secrets store, keyed by the instance ID. This means connection strings, API keys, and other configuration don’t leak between instances. If you’re testing with different Azure resources or database connections across two worktrees, each stays self-contained.<\/p>\n The isolated secrets are stored alongside your normal user secrets but under a separate key, so they don’t interfere with your standard Use it when:<\/p>\n You can still use the standard Aspire 13.2 introduces isolated mode, letting you run multiple instances of the same AppHost in parallel without port conflicts. Learn how the –isolated flag solves development and testing workflows.<\/p>\n","protected":false},"author":11402,"featured_media":373,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1,17],"tags":[26,9,10],"class_list":["post-369","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-aspire-category","category-deep-dives","tag-apphost","tag-aspire","tag-cli"],"acf":[],"blog_post_summary":" Aspire 13.2 introduces isolated mode, letting you run multiple instances of the same AppHost in parallel without port conflicts. Learn how the –isolated flag solves development and testing workflows.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/posts\/369","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/users\/11402"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/comments?post=369"}],"version-history":[{"count":1,"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/posts\/369\/revisions"}],"predecessor-version":[{"id":372,"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/posts\/369\/revisions\/372"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/media\/373"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/media?parent=369"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/categories?post=369"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/tags?post=369"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}--isolated<\/code> flag that gives each run its own random ports and separate configuration, so multiple instances of the same AppHost just work.<\/p>\nThe Problem: Port Collisions in Parallel Development<\/h2>\n
aspire run<\/code><\/pre>\nError: Port 17370 is already in use by another application<\/code><\/pre>\n\n
The Solution: Isolated Mode<\/h2>\n
--isolated<\/code> option to aspire run<\/code> and aspire start<\/code>. This CLI option does two things:<\/p>\n\n
aspire run --isolated<\/code><\/pre>\nReal Scenarios<\/h2>\n
Scenario 1: Working Across Multiple Checkouts<\/h3>\n
cd ~\/projects\/my-app-feature\naspire run --isolated<\/code><\/pre>\ncd ~\/projects\/my-app-bugfix\naspire run --isolated<\/code><\/pre>\nScenario 2: Background Agents in VS Code Copilot Chat<\/h3>\n
--isolated<\/code>, both instances just work:<\/p>\n\n
aspire run --isolated<\/code> in your current checkout<\/li>\naspire run --isolated<\/code> in the auto-created worktree<\/li>\n<\/ul>\naspire agent init<\/code> instructs agents to use --isolated<\/code> when using git worktrees. The Copilot agent should run your Aspire AppHost with isolation automatically.<\/p>\nHow It Works Under the Hood<\/h2>\n
--isolated<\/code>, the CLI generates a unique instance ID for the run. This ID drives two key behaviors:<\/p>\nRandomized Ports<\/h3>\n
Isolated User Secrets<\/h3>\n
aspire run<\/code> configuration.<\/p>\nWhen to Use Isolated Mode<\/h2>\n
\n
aspire run<\/code> for single-project development if you prefer predictable ports.<\/p>\nGet Started<\/h2>\n
\n