Aspire Has Changed: A Catch-Up for the 2025 Crowd

Back when we first wrote about Aspire, it was a very different creature. It was strictly .NET and still quite new, but full of potential. Fast forward a year, and what a year it has been. It’s time to take another look at Aspire and see all the changes it has experienced.

The original pitch for Aspire was that it was an orchestration tool for cloud-based .NET applications. It was even called “.NET Aspire”. A lot of people looked at it and thought “it’s great, but it’s just for local dev work and only my back end is .NET”. And they moved on.

Today, that pitch is both the same and quite different. Now, Aspire (no more .NET in the name) is an app model that runs your whole system locally and publishes it to Compose, Kubernetes, AKS, or Azure Container Apps.

Let’s take a look at all the things you might have missed. A lot has shipped in a short window. Rather than march through it release by release, it’s more useful to group the changes by what they actually unlock for you as a developer.

Deployment Left the Preview Nest

The single biggest shift is that deployment is no longer an experiment you opt into and hope for the best. The pieces that used to live behind preview flags are now stable and, in several cases, generally available.

The Docker Compose publishing integration moved from prerelease to stable in 13.2. That means you can take the same app model you run locally and produce a real Compose file for it without wading through “this may change” warnings.

The CLI’s aspire publish and aspire deploy commands went GA in 13.4. These generate deployment artifacts and push your app out to a target. Between them and the Compose work, the story is now “the thing you describe in your AppHost is the thing you deploy,” whether that target is Docker Compose, Kubernetes, AKS, or Azure Container Apps.

And because deploying is only half of a real workflow, 13.3 added aspire destroy, which tears down what you deployed across Azure Container Apps, App Service, Kubernetes, and Docker Compose. Being able to cleanly stand something up and tear it back down is what turns “I published an artifact” into an actual lifecycle you can trust.

If you aren’t deploying to a container service, you can still deploy Aspire applications using all the same methods that you always have. It’s enhanced, not changed.

The AppHost Went Polyglot

Aspire is no longer just for .NET apps. Aspire now has full, first-class support for JavaScript, TypeScript, Go, and Bun applications, and community support for other platforms continues to expand. It also has full support for .NET console applications, not just the web.

The headline here really is TypeScript. Originally introduced in Aspire 13.2, the TypeScript AppHost went GA in 13.4. This isn’t a bolted-on translation layer, either. It’s the same code-first orchestration model you already know from C#, just expressed in TypeScript. If a capability works in the C# AppHost, like eventing, pipeline steps, Docker Compose customization, Dockerfile building, and custom health checks, then it works from the TypeScript AppHost too.

Go and Bun apps are supported via the new AddGoApp and AddBunApp APIs. These let you orchestrate Go and Bun applications directly, with Go support graduating out of the community packages and into core Aspire.

The practical upshot: that objection from 2025, “this is neat, but only my back end is .NET”, no longer holds. Node, Go, Vue, React, Angular, Bun, and .NET can all live in the same app model, orchestrated together.

The CLI Became a Real Tool

In 2025 the CLI was, charitably, a convenience wrapper. In 2026 it’s a first-class tool that you’ll actually reach for.

For starters, it’s fast. As of 13.3, the CLI ships as a NativeAOT-compiled global tool. That means instant startup with no JIT warmup and no managed runtime dependency riding along in the package. It feels less like a .NET tool and more like a native binary, because it is one.

It also learned some genuinely useful tricks:

• A standalone dashboard. The new aspire dashboard command runs the Aspire dashboard without an AppHost, so you can point any OTLP-emitting application at it and consume its telemetry. The dashboard is no longer married to running a full Aspire app.
• Server-side log and telemetry search. aspire logs and aspire otel now support --search filters, and the search, tail, and resource filters are applied before the data is streamed back to the CLI. You can grep across log messages, structured attributes, span names, and trace IDs without dragging entire datasets over the wire.
• Environment diagnostics. aspire doctor reports your current CLI version, whether an update is available, the AppHost SDK versions it detects, and every Aspire CLI installation on the machine. That last part matters more than it sounds. We’ll look at that more in a moment.
• Integration discovery. aspire integration list and aspire integration search let you browse available hosting integrations from the command line without cracking open your AppHost.
• More ways to install it. As of 13.5, the CLI is available through npm (@microsoft/aspire-cli) and Nix, on top of the existing PowerShell, bash, and dotnet tool options. If your team lives in the JavaScript ecosystem now, you can pull the CLI down with the same package manager you use for everything else.

The Dashboard Became Interactive

The dashboard used to be a great read-only window into your running system. Now you can reach through the glass.

13.5 added terminal sessions via a WithTerminal() API, letting the dashboard attach to REPLs and shells for your resources. It’s a built-in terminal view right there in the browser. The Interaction Service picked up file upload inputs and progress dialogs, so a resource command can now ask you for a file or show you a progress bar while it works, rather than silently succeeding or failing.

On the telemetry side, structured search gained field qualifiers like status:error and @attr:value, along with negation, numeric comparisons, and timestamp filtering. Now, you can narrow in on exactly the traces and logs you care about. Console logs got text search too.

The custom resource commands we covered in our custom commands post now take typed arguments.

The dashboard also got an official visual refresh in 13.5, with a properly branded look and accessibility improvements, so it feels a bit more polished than the one you may remember.

Altogether, the dashboard has quietly turned into a control surface, not just a monitor.

It’s “Aspire” Now, and It Lives at aspire.dev

A smaller change, but one that will bite you if you don’t know about it: the branding moved. It’s just Aspire now, and not “.NET Aspire”. This reflects the fact that it’s no longer a .NET-only tool. The documentation has a new home at aspire.dev, which is now the central hub for docs, getting-started guides, and community resources.

Why does this matter for a catch-up post? Because if you go searching for “.NET Aspire”, the name you knew in 2025, you’ll land on a mix of current and stale material. When you’re verifying something for your own project, start at aspire.dev and confirm the branding and version details there before you trust an older blog or Stack Overflow answer, including this one.

Mind the Version Skew

Here’s one critical piece to be careful of. Aspire ships as a fleet of NuGet packages, and mixing versions across a minor release, such as some 13.4 packages alongside some 13.5 packages, can fail at runtime, and not necessarily at build time. You’ll see it surface as a MissingMethodException or a TypeLoadException when the mismatched assemblies finally try to talk to each other.

So make use of the aspire doctor command, which will report the AppHost SDK versions it detects and flag conflicting or shadowed CLI installations.

The durable fix is to pin every Aspire package to a single version in one place using central package management. Add a Directory.Packages.props at the root of your solution:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
    <AspireVersion>13.5.0</AspireVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Aspire.Hosting.AppHost" Version="$(AspireVersion)" />
    <PackageVersion Include="Aspire.Hosting.SqlServer" Version="$(AspireVersion)" />
    <!-- every other Aspire.* package, all pointed at $(AspireVersion) -->
  </ItemGroup>
</Project>

With central package management on, your individual project files reference packages without a version (<PackageReference Include="Aspire.Hosting.SqlServer" />), and the single AspireVersion property keeps the whole party in lockstep. When you’re ready to move to the next release, you change one line.

Upgrading from a 13.0 or 13.1 AppHost

If your AppHost has been sitting untouched since late 2025, upgrading is worth it, but a few breaking changes will actually bite. The ones to watch as you move up through the 13.x line:

• ServiceProvider became Services. Across the hosting context types, the ServiceProvider property was renamed to Services in 13.5. A quick find-and-replace, but the compiler will let you know.
• PublishAsConnectionString is obsolete. Migrate to AddConnectionString.
• Some aspire ps options were removed (--resources and --include-hidden), so any scripts leaning on them need updating.
• The dashboard’s built-in AI Assistant was removed in 13.5. If you relied on it, note that the MCP server we covered previously is now the supported path for wiring an AI agent into your running app. The result is that it works with whatever agent you prefer, not just one.
• VS Code no longer auto-launches the dashboard by default; you opt in through settings.

There’s one more that specifically catches early adopters. If you tried the TypeScript AppHost preview before 13.4, the file layout changed: apphost.ts became apphost.mts. If you pulled a preview forward and the code generation suddenly falls over, that rename is very likely the culprit. Update the file, run aspire restore to regenerate the integration SDKs, and you should be back in business.

Where This Series Goes From Here

This is the opener for a refreshed look at Aspire. Over the next few posts we’ll dig into the deployment story, the polyglot AppHost, and the grown-up CLI in more detail. In the meantime, here’s how the earlier series holds up so you know what to still trust and what’s been overtaken:

• .NET Aspire - Why We Should Consider It And How To Get Started — Still accurate on the core concepts: the AppHost, the Hosting-vs-client package split, and the integration model all work the way this post describes. Superseded on the name (it’s “Aspire” now) and on the framing that it’s a .NET-first, local-dev tool.
• Aspire CLI — Still accurate on installation. Expanded considerably since: NativeAOT startup, the standalone dashboard, and log/telemetry search are all new, as covered above.
• Aspire MCP Server — Still accurate, and arguably more relevant now that the dashboard’s built-in AI Assistant has been retired in favor of the MCP approach.
• Using Databases In Aspire — Still accurate. The Hosting/client package pattern is unchanged.
• Creating Custom Resource Commands In Aspire — Still accurate, with a bonus: resource commands now accept typed arguments, so you can build richer commands than when we first wrote it.
• Enhancing Telemetry in Aspire — Still accurate, and now complemented by the CLI’s server-side telemetry search for when the dashboard isn’t where you’re working.

If you tried Aspire a year ago and filed it under “neat, but just local dev,” this is the moment to give it another look. The tool you remember is now the local-development half of something considerably bigger.