Aspire 13.2: An AI-Agent CLI, TypeScript AppHosts, and a Dashboard That Exports Everything

If you have spent any time watching a coding agent struggle with your Aspire project — starting the AppHost, waiting for resources, then accidentally stomping on another branch's ports — Aspire 13.2 was clearly built with that pain in mind. Released on 25 March 2026, this update reshapes the CLI around agent-driven workflows, cracks open the AppHost to TypeScript, and turns the dashboard into something you can actually export data from. It is a dense release, so let us focus on the parts that will change how you work day to day.

The CLI gets an agent-shaped redesign

The headline feature is what Microsoft calls an "AI-agent-native CLI." In practice, this means the aspire CLI now has first-class support for the patterns that coding agents (GitHub Copilot, Claude Code, and similar tools) need: background execution, machine-readable output, resource-level control, and health-status polling.

Detached mode and process management

Previously, aspire run blocked the terminal. If a coding agent wanted to start your AppHost, run some tests, and then tear it down, it had to manage process lifecycles itself. Now there is a proper background mode:

aspire start                         # Start AppHost in background (detached)
aspire ps                            # List running AppHost instances
aspire ps --resources --format json  # Machine-readable resource listing
aspire stop                          # Stop all running instances

The --format json flag is the key detail. JSON goes to stdout, status messages go to stderr. An agent can parse the output without scraping human-readable text.

Resource-level commands

Instead of restarting your entire AppHost because one project needs a rebuild, you can now target individual resources:

aspire resource api restart
aspire resource api rebuild

The rebuild command is particularly useful during iterative development. Change a file, rebuild the single project, and the rest of your infrastructure stays warm.

Isolation mode

This one solves a genuine headache. If you are running Aspire across multiple git worktrees — or if a coding agent spins up a parallel environment — port conflicts are inevitable. The --isolated flag randomises ports and creates separate user secrets:

aspire start --isolated

No more hunting down why port 5432 is already in use because another branch's AppHost is still running. Each isolated instance gets its own ports, its own secrets store, and its own lifecycle.

Waiting for resources

Agents need to know when a resource is healthy before running tests against it. The wait command blocks until a resource reaches a specified state:

aspire wait api --status healthy --timeout 120

This replaces fragile polling loops with a single, deterministic command. If the resource does not reach the target status within the timeout, the command exits with a non-zero code.

Built-in documentation access

The CLI can now query aspire.dev documentation directly:

aspire docs search "redis"
aspire docs get redis-integration
aspire docs get redis-integration --section "Add Redis resource"

This is explicitly designed for agents that need context about Aspire integrations without leaving the terminal. Human developers will probably still reach for the browser, but it is useful for scripting too.

Environment diagnostics

Before any of this matters, your environment needs to be correctly set up. The doctor command validates everything an Aspire project needs:

aspire doctor

It checks HTTPS certificates, Docker or Podman availability, .NET SDK version, WSL2 configuration on Windows, and agent-specific config. Think of it as a preflight check.

TypeScript AppHost: Aspire beyond C#

This is the one that raised eyebrows. You can now write your Aspire AppHost in TypeScript:

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const cache = await builder.addRedis("cache");

const api = await builder.addProject("api", "../api")
    .withReference(cache)
    .waitFor(cache);

await builder.build().run();

The app model is the same. Service discovery, the dashboard, the CLI — everything works identically whether your AppHost is C# or TypeScript. The aspire add command inspects .NET assemblies and generates TypeScript SDKs automatically, so you get full type safety for your resource references.

Why this matters

Aspire has always had a "you must know C# to orchestrate" requirement. That is fine when your entire team writes C#, but it becomes a barrier when your platform team includes TypeScript developers, or when your orchestration logic needs to live closer to your Node.js services.

The TypeScript AppHost is in preview, but the VS Code integration already supports CodeLens decorations, gutter state indicators, and native debugging for TypeScript AppHosts. Microsoft has signalled that more languages are coming — TypeScript is the proof of concept.

Configuration consolidation

Aspire projects have accumulated configuration files over time: .aspire/settings.json, apphost.run.json, launch profiles, and various scattered settings. Aspire 13.2 consolidates everything into a single aspire.config.json:

{
  "appHost": {
    "path": "apphost.ts",
    "language": "typescript/nodejs"
  },
  "sdk": {
    "version": "13.2.0"
  },
  "channel": "stable",
  "profiles": {
    "default": {
      "applicationUrl": "https://localhost:17000;http://localhost:15000"
    }
  }
}

Legacy configuration files are auto-migrated. The old files are preserved for backward compatibility, but new projects will only generate aspire.config.json. The aspire config commands let you read and write settings without editing JSON by hand:

aspire config list
aspire config get appHost.path
aspire config set channel preview

Dashboard: export everything

The Aspire dashboard has been a read-only window into your running application. That changes in 13.2 with a proper telemetry export and import system.

Telemetry HTTP API

The dashboard now exposes a REST API for telemetry data:

GET /api/telemetry/resources
GET /api/telemetry/spans
GET /api/telemetry/logs
GET /api/telemetry/traces
GET /api/telemetry/traces/{traceId}

Each endpoint supports ?follow=true for real-time NDJSON streaming. You can pipe trace data into external tools, build custom dashboards, or feed telemetry into your CI pipeline for automated regression detection.

Enable the API with environment variables:

DASHBOARD__API__ENABLED=true
DASHBOARD__API__AUTHMODE=ApiKey
DASHBOARD__API__PRIMARYAPIKEY=your-api-key-here

Export snapshots

The aspire export command creates a complete debug snapshot — traces, logs, resource configuration — as a zip file. Share it with a colleague, attach it to a bug report, or import it into another dashboard instance:

aspire export --output ./artifacts/debug-snapshot.zip
aspire export api  # Export a single resource

The dashboard UI also lets you export individual resources as JSON and environment variables as .env files.

Other dashboard improvements

• Force-directed resource graph. The resource visualisation now automatically positions nodes using a force-directed layout, which handles complex topologies far better than the previous grid.
• Persistent UI state. Collapsed and expanded resource groups, filter preferences, and time format settings now survive page refreshes.
• Data masking. Query string values in trace data are obscured by default, so sensitive parameters do not appear in screenshots or exports.
• OTLP/JSON support. The dashboard accepts OTLP data over JSON alongside the existing gRPC transport, which simplifies integration with tools that do not support gRPC.

New integrations worth knowing about

Microsoft Foundry

The Azure AI Foundry integration has been overhauled and renamed for the next-generation Microsoft Foundry platform:

var foundry = builder.AddFoundry("foundry");
var project = foundry.AddProject("agents");
var chat = project.AddModelDeployment("chat", FoundryModel.OpenAI.Gpt5Mini);

builder.AddPythonApp("agent", "..\\agent", "main:app")
    .WithReference(project)
    .WithReference(chat)
    .PublishAsHostedAgent(project);

Azure Virtual Networks and private endpoints

Aspire can now model VNets, subnets, NAT gateways, and private endpoints directly in the AppHost:

var vnet = builder.AddAzureVirtualNetwork("vnet");

var webSubnet = vnet.AddSubnet("web", "10.0.1.0/24")
    .AllowInbound(
        port: "443",
        from: AzureServiceTags.AzureLoadBalancer,
        protocol: SecurityRuleProtocol.Tcp)
    .DenyInbound(from: AzureServiceTags.Internet);

var peSubnet = vnet.AddSubnet("private-endpoints", "10.0.2.0/27");

var storage = builder.AddAzureStorage("storage");
peSubnet.AddPrivateEndpoint(storage.AddBlobs("blobs"));

This means your deployment topology — network rules, private connectivity, NAT configuration — lives in the same place as your service definitions. No more context-switching between Bicep files and AppHost code.

Docker Compose publishing (now stable)

The Docker Compose publisher, which was preview in Aspire 13, is now stable:

builder.AddDockerComposeEnvironment("compose");

At publish time, Aspire generates a complete docker-compose.yaml from your AppHost model. If your deployment target is not Azure Container Apps or Kubernetes, this gives you a straightforward path to production.

MongoDB EF Core

A new integration wires up MongoDB with Entity Framework Core:

builder.AddMongoDbContext<MyDbContext>("mongodb", databaseName: "appdb");

Breaking changes to watch for

A few renames landed in this release that will bite you during upgrades:

• WithSecretBuildArg is now WithBuildSecret. The old method still compiles but is marked obsolete.
• aspire mcp is now aspire agent mcp. The resource command syntax also changed from positional arguments to the aspire resource <name> <command> structure.
• BeforeResourceStartedEvent now fires only when a resource is actually starting, not on every state change. If you have custom lifecycle hooks that relied on the old behaviour, they may stop firing when you expect them to.
• Azure AI Foundry package and API names changed to Foundry. This is not just a rename — the API surface has changed.

Common pitfalls

Forgetting --isolated in CI. If your CI pipeline runs multiple Aspire-backed test suites in parallel, they will fight over ports. Always use --isolated in automated environments.

Mixing old and new config files. The auto-migration from .aspire/settings.json to aspire.config.json works, but if you manually edit both files, the old one takes precedence in some edge cases. Delete the legacy files once you have confirmed migration.

TypeScript AppHost type generation. The generated TypeScript SDKs in .modules/ must be regenerated after adding new .NET project references. Run aspire restore if your TypeScript AppHost cannot find a project you just added.

Export API authentication. The telemetry API defaults to disabled. If you enable it without setting an auth mode, the dashboard will reject all requests. Always configure DASHBOARD__API__AUTHMODE alongside DASHBOARD__API__ENABLED.

Resource rebuild vs restart. aspire resource api restart stops and starts the resource with existing binaries. aspire resource api rebuild recompiles first. Using restart when you meant rebuild means your code changes will not take effect.

Summary

Aspire 13.2 is a substantial release that reflects where the .NET ecosystem is heading:

• The CLI is now agent-first. Detached mode, JSON output, resource-level control, and health polling make Aspire a first-class citizen in agent-driven workflows.
• TypeScript AppHosts open Aspire orchestration to teams that do not write C#, with more languages planned.
• Configuration is consolidated into a single aspire.config.json, replacing the scattered settings files from earlier versions.
• The dashboard exports data via a REST API with streaming support, and aspire export creates shareable debug snapshots.
• New Azure integrations cover VNets, private endpoints, Data Lake Storage, and the rebranded Microsoft Foundry platform.
• Docker Compose publishing is stable, giving non-cloud deployments a supported path.

Update with aspire update --self && aspire update, and check your project for the breaking changes listed above before you merge.