What's New in Aspire 13: Features Every .NET Enterprise Team Should Adopt in 2026
Aspire 13 is the most significant release in the Aspire product line since its public launch — and it arrives alongside .NET 10 as a statement of intent. With this release, Aspire sheds the ".NET" prefix entirely and evolves from a .NET-centric orchestration tool into a true multi-language application platform. For enterprise .NET teams, the changes go far beyond a rebrand. This release reshapes how distributed applications are developed, debugged, and deployed in 2026.
🎁 Want implementation-ready .NET source code you can drop straight into your project? Join Coding Droplets on Patreon for exclusive tutorials, premium code samples, and early access to new content. 👉 https://www.patreon.com/CodingDroplets
From .NET Aspire to Aspire — What the Rename Signals
The drop of ".NET" from the product name is not cosmetic. It reflects a deliberate architectural decision to support Python and JavaScript as first-class citizens alongside C#. Enterprise teams managing polyglot stacks — a .NET API, a Python ML service, a TypeScript front-end — can now orchestrate all of these from a single Aspire AppHost without maintaining separate tooling ecosystems.
This shift also signals a longer-term roadmap commitment: the multi-language infrastructure Microsoft built for Python and JavaScript is designed to be repeatable, and more languages are expected to follow. If your enterprise is already running .NET alongside other runtimes, Aspire 13 is the first release where it makes sense to evaluate Aspire as the single development orchestrator for your entire system.
Python and JavaScript as First-Class Citizens
Aspire 13 introduces first-class support for Python and JavaScript — not as bolt-ons, but as fully integrated workloads with development, debugging, and deployment parity with .NET.
Python support covers running scripts, modules, and ASGI web frameworks. Teams using FastAPI, Starlette, or Quart alongside ASP.NET Core microservices can now add Python services directly into the AppHost, configure endpoints, enable health checks, and get full Aspire dashboard telemetry — traces, logs, and metrics — with no extra plumbing. Package management is detected automatically (pip, venv, or uv), and Aspire can generate production Dockerfiles for Python workloads.
JavaScript support targets Vite and npm-based applications with automatic package manager detection, debugging support, and container-based build pipelines. This removes a persistent gap for teams that serve a React or Vue front-end alongside .NET APIs.
For enterprise teams, the practical payoff is a consistent local development experience regardless of service runtime. Every developer runs the same aspire run command and gets the same observable, instrumented environment — regardless of whether the service they own is written in C#, Python, or JavaScript.
The aspire init Command — Aspirify Existing Applications
One of the most requested features from enterprise teams was a way to bring existing applications into Aspire without starting from scratch. Aspire 13 delivers this with the aspire init command.
Running aspire init in an existing project directory analyzes the codebase and generates a minimal AppHost scaffolding that wires up the detected services. This is a meaningful quality-of-life improvement for large organisations with established codebases that want to adopt Aspire incrementally — without a full rewrite or risky migration sprint.
Paired with aspire new for greenfield projects, the CLI now provides a complete project lifecycle entry point: init to onboard, new to start fresh, and update to upgrade Aspire packages across the board. Enterprise teams running Central Package Management (CPM) are explicitly supported.
TypeScript AppHost — Preview in 13.2
Aspire 13.2 shipped a preview feature that deserves immediate attention: the ability to write the Aspire AppHost in TypeScript, not just C#.
The Aspire AppHost is the orchestration layer — it defines which services run, how they connect, and what infrastructure they need. In earlier versions, this was C# only. With TypeScript AppHost support, teams that prefer a JavaScript/TypeScript-first developer experience can now own the orchestration layer without switching languages.
Critically, the CLI, VS Code extension, and dashboard all behave identically whether the AppHost is written in C# or TypeScript. There is no loss of capability — full service discovery, telemetry, and resource management work across both. For enterprise teams with a significant TypeScript investment, this removes one of the last friction points in Aspire adoption.
AI-Agent-Native CLI — Built for Automated Workflows
Aspire 13.2 introduced one of the more forward-looking features in the release: a CLI designed to work with coding agents.
The aspire start --detach mode allows agents to start an AppHost in the background without blocking. Agents can then issue targeted commands — restart a single resource, check its health status, wait for it to reach a healthy state — without tearing down and rebuilding the entire environment. The --isolated flag provides parallel, conflict-free environments for agents working in separate git worktrees: random ports, isolated secrets, and no dependency collisions.
The aspire docs command brings aspire.dev documentation directly into agent context, enabling agents to retrieve up-to-date reference material programmatically without additional MCP configuration. aspire doctor validates the full environment before an agent begins any automated workflow.
For enterprise teams adopting AI-assisted development workflows — whether GitHub Copilot, Claude, or internal tooling — this is significant. It means Aspire environments can be spun up, tested, and torn down programmatically as part of CI/CD pipelines or developer agent loops, not just interactively.
Dashboard Improvements in 13.2
The Aspire dashboard received targeted but impactful upgrades in 13.2 that matter for enterprise debugging workflows.
Export and import of telemetry bundles is the headline improvement. Developers and operators can now export traces, spans, logs, and resource configurations as JSON or .env bundles using aspire export, then share them with teammates or attach them to issue reports. A teammate can import that bundle into their local dashboard and replay the exact debugging context without needing to reproduce the problem themselves.
Additional highlights:
- Improved GenAI visualizer: Better schema handling and tool call inspection for teams using AI service integrations
- Query string masking: Sensitive data in URLs is masked by default in the dashboard — relevant for teams handling PII or tokens in query parameters
- OTLP/JSON transport: Support for OTLP over JSON in addition to gRPC, which simplifies integration with tooling that supports JSON but not gRPC
- Persistent UI state: Collapsed/expanded resource states and active filters survive page refreshes and navigation
- Adaptive resource graph: Force-directed layout adapts more gracefully to large, complex service graphs
For teams operating in regulated environments, the query string masking and export/import workflow alone justify evaluating the upgrade.
Simplified AppHost Project Structure
Aspire 13.0 cleaned up the AppHost project file format in a way that enterprise teams maintaining large numbers of microservices will appreciate. The SDK is now specified as Sdk="Aspire.AppHost.Sdk/13.0.0" directly in the <Project> tag, eliminating the separate <Sdk> element and the explicit Aspire.Hosting.AppHost package reference. The SDK now includes it automatically.
The aspire update command handles this migration automatically when upgrading from 9.x to 13.0. For teams managing dozens of AppHost projects, this is a maintenance reduction — fewer lines in project files and fewer explicit version pins to coordinate during upgrades.
What to Adopt Now vs. What to Evaluate Later
Not every Aspire 13 feature is equally ready for production adoption. Here is a practical framework for enterprise teams:
Adopt now:
aspire initfor onboarding existing services — low risk, high leverage- AppHost project structure simplification — handled automatically by
aspire update - Dashboard telemetry export/import for debugging workflows
- Python integration if your team already runs Python services alongside .NET
Evaluate for Q3/Q4 2026:
- TypeScript AppHost (currently in preview — API surface may change before GA)
- AI-agent-native CLI features (valuable for teams actively building agentic CI/CD pipelines)
- JavaScript integration for brownfield front-end services
Watch but defer:
- Multi-language AppHost beyond TypeScript (more languages expected, timing unknown)
Enterprise teams on .NET 9 should note that Aspire 13.0 requires the .NET 10 SDK. If your team is not yet on .NET 10, the upgrade path runs through the SDK version, and the aspire update command handles the Aspire-side migration automatically once .NET 10 SDK is in place.
For teams assessing the broader .NET 10 ecosystem alongside Aspire 13, the .NET 10 LTS Upgrade Strategy for Enterprise Teams post covers the upgrade decision framework in detail. If you are evaluating how observability fits into your Aspire setup, OpenTelemetry in ASP.NET Core: A Complete Guide for .NET Developers walks through the instrumentation approach that Aspire builds on.
☕ Prefer a one-time tip? Buy us a coffee — every bit helps keep the content coming!
Frequently Asked Questions
What .NET version does Aspire 13 require?
Aspire 13.0 requires the .NET 10 SDK or later. Teams on .NET 9 will need to install the .NET 10 SDK before upgrading Aspire. The Aspire-side upgrade is handled by aspire update, but the SDK upgrade must be done manually through your normal SDK management process.
Can I use Aspire 13 with a C# AppHost if I do not want TypeScript?
Yes. TypeScript AppHost is an optional preview feature in 13.2. C# remains fully supported as the primary AppHost language, and all existing C# AppHost projects continue to work without modification after running aspire update.
Is the multi-language support (Python, JavaScript) production-ready in Aspire 13? Python and JavaScript integration shipped as stable features in 13.0. TypeScript AppHost authoring is in preview as of 13.2. For production workloads using Python or JavaScript services orchestrated by a C# AppHost, the integration is considered stable.
How does Aspire 13 handle service discovery across languages? Connection properties — URIs, JDBC strings, or individual host/port/credentials — are propagated across all supported languages through a unified mechanism. A Python FastAPI service can receive the connection string for a Redis resource defined in the AppHost the same way a C# service would. This is part of the multi-language infrastructure Microsoft built into the 13.0 foundation.
What is the aspire export command used for?
aspire export (introduced in 13.2) captures a snapshot of your running Aspire environment — including traces, spans, logs, and resource configurations — and exports them as a bundle. This bundle can be shared with teammates or imported into any Aspire dashboard instance, enabling remote debugging collaboration without needing to reproduce the problem in a separate environment.
Does Aspire 13 change how existing integrations (Redis, PostgreSQL, etc.) work?
Existing integrations continue to work without breaking changes. Aspire 13.2 added new integrations (Certbot, updated Azure AI Foundry, Bun for JavaScript) and improved existing ones, but the core integration model is unchanged. The aspire update command updates all integration package versions automatically.
What does the AI-native CLI mean for enterprise CI/CD pipelines? The CLI improvements in 13.2 allow automated agents and CI scripts to start Aspire environments in detached mode, control individual resources (start, stop, restart), and wait for health status changes programmatically. This makes it feasible to use Aspire as the orchestration layer in integration test pipelines — spinning up a real service graph, running tests, and tearing it down without manual intervention.
