Aspire | The .NET Blog

Private Endpoints, VNets, NSGs — Aspire Handles the Networking Now

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

Here’s a scenario I’ve seen too many times. The app is done. The demo is great. Then the security checklist shows up: take storage off the public internet, run inside a VNet, provide outbound IPs for the partner allowlist, prove that only the right subnets talk to the right services.

At that point the application model and the infrastructure model start drifting apart in ways that are painful to maintain.

Aspire’s new Azure enterprise networking support addresses this directly. You describe the network shape next to the resources that use it, in your AppHost.

The Building Blocks

Here’s what each Azure networking concept is for, distilled:

Feature	Use it when	Why it matters
Virtual network	You need a private address space	The network boundary for subnets, private endpoints, and routing
Subnet	You need to separate workloads inside the VNet	Each part of the system gets its own address range and policy surface
Delegated subnet	A platform service (like ACA) needs to manage a subnet	Lets the service place managed infrastructure in your VNet safely
NAT gateway	You need predictable outbound public IPs	Stable address for allowlists and auditing
Private endpoint	You want a PaaS resource reachable privately	Puts a private IP for that service inside your VNet, removes public exposure
NSG	You need subnet-level traffic rules	Explicit allow/deny for inbound and outbound traffic per subnet

Describing It in Your AppHost

The key shift here is that you’re modeling the network alongside the resources that use it, not in a separate Bicep file that drifts away from the app model over time.

From the AppHost, you can:

Create VNets and subnets with AddVirtualNetwork() and AddSubnet()
Attach a NAT gateway to subnets for stable outbound IPs
Create private endpoints for storage, Key Vault, SQL, and other PaaS services
Define NSGs with inbound and outbound security rules
Configure Network Security Perimeters for cross-resource policies

The result is that when you run azd up, the infrastructure matches what the app model says it needs. Not what a manually maintained template says.

Why This Matters for Real Applications

A few things that become significantly easier once the network is modeled in Aspire:

Private endpoints for Key Vault and storage — you describe WithPrivateEndpoint() on those resources, and Aspire handles the DNS zone configuration and endpoint attachment. The app never changes.

Consistent outbound IPs — add a NAT gateway to the relevant subnet and every outbound request from your app goes through a known, stable IP. Partners can allowlist it. Auditors can trace it.

NSG rules from code — instead of clicking through the portal or maintaining a Bicep snippet, your security rules live in the AppHost alongside the resources they protect.

This is the kind of integration that doesn’t make demos exciting but makes production systems maintainable.

Wrapping Up

Network security showing up late in the project lifecycle is a solved problem if you model it alongside the app from the start. Aspire’s enterprise networking support makes that possible without requiring a separate infrastructure track.

Full details in the original post: Securing Azure apps with Aspire enterprise networking

Aspire 13.3: Kubernetes Support, Browser Logs, and the Aspireify Skill

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Five weeks is not a long time for a release, but Aspire 13.3 doesn’t feel like it. The headline items are meaningful: first-class Kubernetes and AKS deployment with Helm, an agent-assisted onboarding skill called Aspireify, browser log capture directly in the dashboard, and structured command results. Plus 45 new features, 134 improvements, and 93 bug fixes.

Let’s hit the highlights.

Aspireify: Agent-Assisted Onboarding

Adding Aspire to an existing project sounds simple — drop an AppHost in, done. In practice it involves a lot of archaeology: which ports matter, which environment variables are real dependencies, which Docker Compose services should map to Aspire integrations.

The new Aspireify skill gives your coding agent a guided workflow for exactly this. When aspire init drops a skeleton AppHost, the Aspireify skill helps the agent inspect the repo, understand how it already runs, and wire the AppHost to fit the app — not the other way around.

The default stance is “minimize changes to your code.” If your app already reads DATABASE_URL, the agent maps that with WithEnvironment() instead of asking you to rewrite your configuration. If a port is hardcoded, the skill tells the agent when to preserve it.

This is the kind of AI tooling that actually saves time rather than generating more work to review.

First-Class Kubernetes and AKS Deployment

This one has been on the wishlist for a while. Aspire 13.3 ships first-class Kubernetes and AKS deployment support with Helm. You can now target AKS as a deployment target directly from the Aspire tooling.

For teams already running production workloads on AKS, this closes a significant gap. Your Aspire app model now has a clean path from local dev to Kubernetes without manual Helm chart authoring.

Browser Logs in the Dashboard

This is one of those features that sounds small until you’re debugging a frontend issue.

The new WithBrowserLogs() API attaches a tracked browser resource to any endpoint-capable resource. Aspire launches Chromium using a private CDP pipe and streams console logs, network requests, and errors directly into the resource log stream:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

TypeScript AppHost supports the same:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Console errors, failed network requests, client-side exceptions — all visible in the same dashboard where you’re already watching traces and metrics. No more tab-switching to browser DevTools for the basic stuff.

Structured Command Results

Resource commands got a meaningful upgrade. Until now, commands returned success/failure. Now they return structured results: text, JSON, or markdown that flows through the model, dashboard UI, CLI, and MCP tools.

The dashboard ties this together with a new notification center in the header. Command results show up as timestamped notifications with markdown rendering and a “View response” action.

This makes resource commands genuinely composable. An integration can now expose a command that returns meaningful output — like a tunnel URL — rather than just changing state somewhere.

Wrapping Up

Aspire 13.3 is worth the upgrade even just for the Kubernetes support. The browser logs and structured command results feel like the kind of quality-of-life improvements that accumulate quickly in a day-to-day development workflow.

Full release notes: What’s New in Aspire 13.3

Aspire 13.2 Gets Bun, Better Containers, and Less Debugging Friction

Emiliano Montesdeoca — Fri, 24 Apr 2026 00:00:00 +0000

If you’ve been building .NET backends with JavaScript frontends in Aspire, 13.2 is the kind of update that quietly makes your day better. No splashy new paradigms. Just solid improvements to things that were mildly annoying.

Let’s walk through what actually landed.

Bun is Now a First-Class Citizen

The headline feature: Bun support for Vite apps in Aspire. One fluent call, done.

// TypeScript AppHost
const builder = await createBuilder();

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

await builder.build().run();

If your team already uses Bun — which you might, given its dramatically faster install times and startup — Aspire no longer makes you fight against the grain. Previously, Aspire assumed npm and you had to work around it. Now .withBun() is a first-class option alongside .withYarn() and the default npm behavior.

Why does this matter? Because JavaScript tooling speed directly affects your inner dev loop. If your frontend takes 30 seconds to install dependencies every time you spin up a fresh environment, that adds up. Bun cuts that dramatically.

The C# AppHost equivalents are documented at aspire.dev if you prefer authoring in C# — all the same patterns apply.

Yarn Got More Reliable

Bun gets the spotlight, but Yarn users get something arguably more impactful: fewer mysterious failures. Aspire 13.2 improves reliability for withYarn() with addViteApp().

These kinds of fixes don’t sound exciting until you’ve spent 20 minutes debugging why your Yarn-backed frontend resource wouldn’t start. Consider it fixed.

Container Publishing You Can Actually Reason About

Two container improvements worth knowing:

Explicit Pull Policy

Docker Compose publishing now supports PullPolicy, including a Never option:

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

const builder = await createBuilder();
await builder.addDockerComposeEnvironment("compose");

const worker = await builder.addContainer("worker", "myorg/worker:latest")
 .withImagePullPolicy(ImagePullPolicy.Never);

await builder.build().run();

This is the “please use the image I already built and leave the registry out of it” workflow. Super useful when iterating locally on images you’re building and publishing manually, or when your CI produces an image and you want Compose to use exactly that one without sneaking in a remote pull.

PostgreSQL 18+ Volumes Work Again

PostgreSQL 18 changed its internal data directory layout. This broke volume mapping in Aspire silently — your data volume would be set up but persistence wouldn’t actually work correctly. 13.2 fixes this.

const postgres = await builder.addPostgres("postgres")
 .withDataVolume({ isReadOnly: false });

If you’re running PostgreSQL 18 or later with a data volume, upgrade to Aspire 13.2 and don’t think about it again.

Debugging Quality-of-Life Improvements

A few things that make stepping through an AppHost session less frustrating:

DebuggerDisplayAttribute on core types — DistributedApplication, resources, endpoint expressions now show useful values in the debugger instead of requiring you to drill into object trees
Better WaitFor failure messages — when resources fail to start, the error context is actually helpful now
BeforeResourceStartedEvent fires at the right time — only when a resource is actually starting, not on unrelated state transitions
launchSettings.json is more resilient — less chance of a malformed setting corrupting your dev startup

None of these are individually earth-shattering, but collectively they remove friction from the debugging experience. If you’ve ever had to drill three levels deep into an Aspire resource object to figure out what endpoint it was using, the debugger display improvement alone is worth the update.

Wrapping up

Aspire 13.2 is a focused quality release. Bun support is the headline, but the container and debugging improvements are what will make your day-to-day work smoother. Worth updating — especially if you’re on PostgreSQL 18 with data volumes.

Full details in the original post by David Pine and the Aspire 13.2 what’s new docs.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 takes place on April 18, 2026 at Kinépolis Diversia in Alcobendas, Madrid. It’s the largest community-driven Azure event in Spain, bringing together 38 speakers across 3 parallel tracks covering AI agents, Azure networking, Cosmos DB, Fabric, IoT, security, and much more.

The event runs from 08:30 to 18:30 and includes keynote, coffee breaks, lunch, and a closing Q&A session.

Highlights from the agenda

Domando Agentes de IA: governance, tools, and APIs with Azure AI Foundry and Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: multi-agent systems in action
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Tickets

Registration is a symbolic donation — the full ticket price goes directly to Plan International, supporting children’s rights and equality worldwide. Limited capacity, so grab your spot early.

Azure Tour 2026

Beyond Madrid, the Global Azure Tour 2026 also includes stops in Zaragoza, Tenerife, and Sevilla.

Stop Babysitting Your Terminal: Aspire's Detached Mode Changes the Workflow

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

Every time you run an Aspire AppHost, your terminal is gone. Locked. Occupied until you Ctrl+C out of it. Need to run a quick command? Open another tab. Want to check logs? Another tab. It’s a small friction that adds up fast.

Aspire 13.2 fixes this. James Newton-King wrote up the full details, and honestly, this is one of those features that immediately changes how you work.

Detached mode: one command, terminal back

aspire start

That’s the shorthand for aspire run --detach. Your AppHost boots up in the background and you get your terminal back immediately. No extra tabs. No terminal multiplexer. Just your prompt, ready to go.

Managing what’s running

Here’s the thing — running in the background is only useful if you can actually manage what’s out there. Aspire 13.2 ships a full set of CLI commands for exactly that:

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

This turns the Aspire CLI into a proper process manager. You can start multiple AppHosts, check their status, tail their logs, and shut them down — all from a single terminal session.

Combine it with isolated mode

Detached mode pairs naturally with isolated mode. Want to run two instances of the same project in the background without port conflicts?

aspire start --isolated
aspire start --isolated

Each gets random ports, separate secrets, and its own lifecycle. Use aspire ps to see both, aspire stop to kill whichever you’re done with.

Why this is huge for coding agents

This is where it gets really interesting. A coding agent working in your terminal can now:

Start the app with aspire start
Query its state with aspire describe
Check logs with aspire logs to diagnose issues
Stop it with aspire stop when done

All without losing the terminal session. Before detached mode, an agent that ran your AppHost would lock itself out of its own terminal. Now it can start, observe, iterate, and clean up — exactly how you’d want an autonomous agent to work.

The Aspire team leaned into this. Running aspire agent init sets up an Aspire skill file that teaches agents these commands. So tools like Copilot’s coding agent can manage your Aspire workloads out of the box.

Wrapping up

Detached mode is a workflow upgrade disguised as a simple flag. You stop context-switching between terminals, agents stop blocking themselves, and the new CLI commands give you real visibility into what’s running. It’s practical, it’s clean, and it makes the daily development loop noticeably smoother.

Read the full post for all the details and grab Aspire 13.2 with aspire update --self.

.NET Aspire 13.2 Wants to Be Your AI Agent's Best Friend

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

You know that moment when your AI coding agent writes some solid code, you get excited, and then it completely falls apart trying to actually run the thing? Port conflicts, phantom processes, wrong environment variables — suddenly your agent is burning tokens troubleshooting startup issues instead of building features.

The Aspire team just dropped a really thoughtful post about exactly this problem, and their answer is compelling: Aspire 13.2 is designed not just for humans, but for AI agents.

The problem is real

AI agents are incredible at writing code. But shipping a working full-stack app involves way more than generating files. You need to start services in the right order, manage ports, set environment variables, connect databases, and get feedback when things break. Right now, most agents handle all of this through trial-and-error — running commands, reading error output, trying again.

We layer on Markdown instructions, custom skills, and prompts to try to guide them, but those are unpredictable, can’t be compiled, and cost tokens just to parse. The Aspire team nailed the core insight: agents need compilers and structured APIs, not more Markdown.

Aspire as agent infrastructure

Here’s what Aspire 13.2 brings to the agentic development table:

Your entire stack in typed code. The AppHost defines your full topology — API, frontend, database, cache — in compilable TypeScript or C#:

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

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

An agent can read this to understand app topology, add resources, wire up connections, and build to verify. The compiler tells it immediately if something is wrong. No guessing, no trial-and-error with config files.

One command to rule them all. Instead of agents juggling docker compose up, npm run dev, and database startup scripts, everything is just aspire start. All resources launch in the right order, on the right ports, with the right configuration. Long-running processes don’t hang the agent either — Aspire manages them.

Isolated mode for parallel agents. With --isolated, each Aspire run gets its own random ports and separate user secrets. Got multiple agents working across git worktrees? They won’t collide. This is huge for tools like VS Code’s background agents that spin up parallel environments.

Agent eyes through telemetry. Here’s where it gets really powerful. The Aspire CLI exposes full OpenTelemetry data during development — traces, metrics, structured logs. Your agent isn’t just reading console output and hoping for the best. It can trace a failing request across services, profile slow endpoints, and pinpoint exactly where things break. That’s production-grade observability in the development loop.

The bowling bumper analogy

The Aspire team uses a great analogy: think of Aspire as bowling lane bumpers for AI agents. If the agent isn’t perfect (and it won’t be), the bumpers keep it from throwing gutter balls. The stack definition prevents misconfiguration, the compiler catches errors, the CLI handles process management, and the telemetry provides the feedback loop.

Pair this with something like Playwright CLI, and your agent can actually use your app — clicking through flows, checking the DOM, seeing broken things in telemetry, fixing the code, restarting, and testing again. Build, run, observe, fix. That’s the autonomous development loop we’ve been chasing.

Getting started

New to Aspire? Install the CLI from get.aspire.dev and follow the getting started guide.

Already using Aspire? Run aspire update --self to get 13.2, then point your favorite coding agent at your repo. You might be surprised how much further it gets with Aspire’s guardrails in place.

Wrapping up

Aspire 13.2 isn’t just a distributed app framework anymore — it’s becoming essential agent infrastructure. Structured stack definitions, one-command startup, isolated parallel runs, and real-time telemetry give AI agents exactly what they need to go from writing code to shipping apps.

Read the full post from the Aspire team for all the details and demo videos.

Aspire's Isolated Mode Fixes the Port Conflict Nightmare for Parallel Development

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

If you’ve ever tried running two instances of the same project at the same time, you know the pain. Port 8080 is already in use. Port 17370 is taken. Kill something, restart, juggle environment variables — it’s a productivity killer.

This problem is getting worse, not better. AI agents create git worktrees to work independently. Background agents spin up separate environments. Developers checkout the same repo twice for feature branches. Every one of these scenarios hits the same wall: two instances of the same app fighting over the same ports.

Aspire 13.2 fixes this with a single flag. James Newton-King from the Aspire team wrote up the full details, and it’s one of those “why didn’t we have this sooner” features.

The fix: `--isolated`

aspire run --isolated

That’s it. Each run gets:

Random ports — no more collisions between instances
Isolated user secrets — connection strings and API keys stay separate per instance

No manual port reassignment. No environment variable juggling. Each run gets a fresh, collision-free environment automatically.

Real scenarios where this shines

Multiple checkouts. You’ve got a feature branch in one directory and a bugfix in another:

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Both run without conflicts. The dashboard shows what’s running and where.

Background agents in VS Code. When Copilot Chat’s background agent creates a git worktree to work on your code independently, it may need to run your Aspire AppHost. Without --isolated, that’s a port collision with your primary worktree. With it, both instances just work.

The Aspire skill that ships with aspire agent init automatically instructs agents to use --isolated when working in worktrees. So Copilot’s background agent should handle this out of the box.

Integration tests alongside development. Need to run tests against a live AppHost while continuing to build features? Isolated mode gives each context its own ports and config.

How it works under the hood

When you pass --isolated, the CLI generates a unique instance ID for the run. This drives two behaviors:

Port randomization — instead of binding to predictable ports defined in your AppHost config, isolated mode picks random available ports for everything — the dashboard, service endpoints, all of it. Service discovery adjusts automatically, so services find each other regardless of which ports they land on.
Secret isolation — each isolated run gets its own user secrets store, keyed by the instance ID. Connection strings and API keys from one run don’t leak into another.

Your code doesn’t need any changes. Aspire’s service discovery resolves endpoints at runtime, so everything connects correctly regardless of port assignment.

When to use it

Use --isolated when running multiple instances of the same AppHost simultaneously — whether that’s parallel development, automated tests, AI agents, or git worktrees. For single-instance development where you prefer predictable ports, regular aspire run still works fine.

Wrapping up

Isolated mode is a small feature that solves a real, increasingly common problem. As AI-assisted development pushes us toward more parallel workflows — multiple agents, multiple worktrees, multiple contexts — the ability to just spin up another instance without fighting over ports is essential.

Read the full post for all the technical details and try it out with aspire update --self to get 13.2.

Aspire 13.2 Ships a Docs CLI — and Your AI Agent Can Use It Too

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

You know that moment when you’re deep in an Aspire AppHost, wiring up integrations, and you need to check exactly which parameters the Redis integration expects? You alt-tab to your browser, hunt through aspire.dev, squint at the API docs, then come back to your editor. Context lost. Flow broken.

Aspire 13.2 just shipped a fix for that. The aspire docs CLI lets you search, browse, and read official Aspire documentation directly from your terminal. And because it’s backed by reusable services, AI agents and skills can use the same commands to look up docs instead of hallucinating APIs that don’t exist.

The problem this actually solves

David Pine nails it in the original post: AI agents were terrible at helping developers build Aspire apps. They’d recommend dotnet run instead of aspire run, reference learn.microsoft.com for docs that live on aspire.dev, suggest outdated NuGet packages, and — my personal favorite — hallucinate APIs that don’t exist.

Why? Because Aspire was .NET-specific far longer than it’s been polyglot, and LLMs are working off training data that predates the latest features. When you give an AI agent the ability to actually look up the current docs, it stops guessing and starts being useful.

Three commands, zero browser tabs

The CLI is refreshingly simple:

List all docs

aspire docs list

Returns every documentation page available on aspire.dev. Need machine-readable output? Add --format Json.

Search for a topic

aspire docs search "redis"

Searches both titles and content with weighted relevance scoring. Same search engine that powers the documentation tooling internally. You get ranked results with titles, slugs, and relevance scores.

Read a full page (or just one section)

aspire docs get redis-integration

Streams the full page as markdown to your terminal. Need just one section?

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

Surgical precision. No scrolling through 500 lines. Just the part you need.

The AI agent angle

Here’s where it gets interesting for us developers building with AI tooling. The same aspire docs commands work as tools for AI agents — through skills, MCP servers, or simple CLI wrappers.

Instead of your AI assistant making up Aspire APIs based on stale training data, it can call aspire docs search "postgres", find the official integration docs, read the right page, and give you the documented approach. Real-time, current documentation — not what the model memorized six months ago.

The architecture behind this is intentional. The Aspire team built reusable services (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) rather than a one-off integration. That means the same search engine works for humans in the terminal, AI agents in your editor, and automation in your CI pipeline.

Real-world scenarios

Quick terminal lookups: You’re three files deep and need Redis config parameters. Two commands, ninety seconds, back to work:

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI-assisted development: Your VS Code skill wraps the CLI commands. You ask “Add a PostgreSQL database to my AppHost” and the agent looks up the real docs before answering. No hallucinations.

CI/CD validation: Your pipeline validates AppHost configurations against official documentation programmatically. --format Json output pipes cleanly to jq and other tools.

Custom knowledge bases: Building your own AI tooling? Pipe structured JSON output directly into your knowledge base:

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

No web scraping. No API keys. Same structured data the docs tooling uses internally.

The documentation is always live

This is the part I appreciate most. The CLI doesn’t download a snapshot — it queries aspire.dev with ETag-based caching. The moment the docs update, your CLI and any skill built on top of it reflects that. No stale copies, no “but the wiki said…” moments.

Wrapping up

aspire docs is one of those small features that solves a real problem cleanly. Humans get terminal-native documentation access. AI agents get a way to stop guessing and start referencing actual docs. And it’s all backed by the same source of truth.

If you’re building with .NET Aspire and haven’t tried the CLI yet, run aspire docs search "your-topic-here" and see how it feels. Then consider wrapping those commands into whatever AI skill or automation setup you’re using — your agents will thank you.

Check out David Pine’s deep dive on how the docs tooling came together, and the official CLI reference for all the details.

Aspire 13.2's Dashboard Just Got a Telemetry API — and It Changes Everything

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

If you’ve been building distributed apps with .NET Aspire, you already know the dashboard is the single best thing about the whole experience. All your traces, logs, and metrics in one place — no external Jaeger, no Seq setup, no “let me check the other terminal” moments.

Aspire 13.2 just made it significantly better. James Newton-King announced the update, and honestly? The telemetry export and API features alone are worth the upgrade.

Export telemetry like a sane person

Here’s the scenario we’ve all lived through: you’re debugging a distributed issue, you finally reproduce it after twenty minutes of setup, and now you need to share what happened with your team. Before? Screenshots. Copy-pasting trace IDs. The usual mess.

Aspire 13.2 adds a proper Manage logs and telemetry dialog where you can:

Clear all telemetry (useful before a repro attempt)
Export selected telemetry to a ZIP file in standard OTLP/JSON format
Re-import that ZIP into any Aspire dashboard later

That last part is the killer feature. You reproduce a bug, export the telemetry, attach it to your work item, and your teammate can import it into their own dashboard to see exactly what you saw. No more “can you reproduce it on your machine?”

Individual traces, spans, and logs also get an “Export JSON” option in their context menus. Need to share one specific trace? Right-click, copy JSON, paste into your PR description. Done.

The telemetry API is the real game changer

This is what I’m most excited about. The dashboard now exposes an HTTP API under /api/telemetry for querying telemetry data programmatically. Available endpoints:

GET /api/telemetry/resources — list resources with telemetry
GET /api/telemetry/spans — query spans with filters
GET /api/telemetry/logs — query logs with filters
GET /api/telemetry/traces — list traces
GET /api/telemetry/traces/{traceId} — get all spans for a specific trace

Everything comes back in OTLP JSON format. This powers the new aspire agent mcp and aspire otel CLI commands, but the real implication is bigger: you can now build tooling, scripts, and AI agent integrations that query your app’s telemetry directly.

Imagine an AI coding agent that can look at your actual distributed traces while debugging. That’s not hypothetical anymore — that’s what this API enables.

GenAI telemetry gets practical

If you’re building AI-powered apps with Semantic Kernel or Microsoft.Extensions.AI, you’ll appreciate the improved GenAI telemetry visualizer. Aspire 13.2 adds:

AI tool descriptions rendered as Markdown
A dedicated GenAI button on the traces page for quick AI trace access
Better error handling for truncated or non-standard GenAI JSON
Click-to-highlight navigation between tool definitions

The blog post mentions that VS Code Copilot chat, Copilot CLI, and OpenCode all support configuring an OTEL_EXPORTER_OTLP_ENDPOINT. Point them at the Aspire dashboard and you can literally watch your AI agents think in real time through telemetry. That’s a debugging experience you won’t find anywhere else.

Wrapping up

Aspire 13.2 takes the dashboard from “nice debugging UI” to “programmable observability platform.” The export/import workflow alone saves real time on distributed debugging, and the telemetry API opens the door to AI-assisted diagnostics.

If you’re already on Aspire, upgrade. If you’re not — this is a good reason to check out aspire.dev and see what the fuss is about.

Aspire | The .NET Blog

Private Endpoints, VNets, NSGs — Aspire Handles the Networking Now

The Building Blocks

Describing It in Your AppHost

Why This Matters for Real Applications

Wrapping Up

Aspire 13.3: Kubernetes Support, Browser Logs, and the Aspireify Skill

Aspireify: Agent-Assisted Onboarding

First-Class Kubernetes and AKS Deployment

Browser Logs in the Dashboard

Structured Command Results

Wrapping Up

Aspire 13.2 Gets Bun, Better Containers, and Less Debugging Friction

Bun is Now a First-Class Citizen

Yarn Got More Reliable

Container Publishing You Can Actually Reason About

Explicit Pull Policy

PostgreSQL 18+ Volumes Work Again

Debugging Quality-of-Life Improvements

Wrapping up

Global Azure Spain 2026

Highlights from the agenda

Tickets

Azure Tour 2026

Stop Babysitting Your Terminal: Aspire's Detached Mode Changes the Workflow

Detached mode: one command, terminal back

Managing what’s running

Combine it with isolated mode

Why this is huge for coding agents

Wrapping up

.NET Aspire 13.2 Wants to Be Your AI Agent's Best Friend

The problem is real

Aspire as agent infrastructure

The bowling bumper analogy

Getting started

Wrapping up

Aspire's Isolated Mode Fixes the Port Conflict Nightmare for Parallel Development

The fix: --isolated

Real scenarios where this shines

How it works under the hood

When to use it

Wrapping up

Aspire 13.2 Ships a Docs CLI — and Your AI Agent Can Use It Too

The problem this actually solves

Three commands, zero browser tabs

List all docs

Search for a topic

Read a full page (or just one section)

The AI agent angle

Real-world scenarios

The documentation is always live

Wrapping up

Aspire 13.2's Dashboard Just Got a Telemetry API — and It Changes Everything

Export telemetry like a sane person

The telemetry API is the real game changer

GenAI telemetry gets practical

Wrapping up

The fix: `--isolated`