Aspire 13.4 is here

By our measure, Aspire 13.4 is a “small” release: only 519 PRs closed in the 3-ish weeks we spent on this one. Casual numbers! But, it still packs a punch. We’ve been hard at work maturing our newest features and optimizing Aspire for every developer.

First and foremost: we loved hearing your excitement around the TypeScript apphost over the last few preview releases, and we’re excited to promote it to General Availability in 13.4. Resource commands got another upgrade too: in 13.3 we gave you command results, and now they can take typed arguments too. We also expanded our Kubernetes and AKS support, tuned the CLI for better AI token efficiency, added Go and Bun integration support to the main repo, and worked through a pile of smaller feedback items you’ve shared with us along the way.

Here are some of my personal favorites from this release, but as always, the full details are over on What’s New in Aspire 13.4.

🌐 TypeScript apphost is officially GA

Good things come to those who wait, and we’ve waited a long time to get TypeScript apphost support to GA.

Over the last few releases, we introduced the first language besides C# you can author your apphost in: TypeScript. 13.4 is where that work graduates to General Availability.

We heard you loud and clear: dropping a .ts file at the root of your repo was going to anger your linters and compilers, especially if you use CommonJS. New TypeScript apphosts now use the more explicit apphost.mts entry point, generated SDK modules live under .aspire/modules/, and startup validation runs before the app does so config mistakes surface early instead of mid-run. The docs now show TypeScript examples right alongside C# too.

The goal here was never “C# apphost, but translated.” It was giving JS and TS developers the same code-first Aspire model in a shape that feels native to them. 13.4 is the culmination of all of that. And because we architected it to be infinitely scalable, we have 3 new apphost languages in preview you can try – Python, Java, and Go.

If you want to dive deeper, check out the TypeScript apphost docs, Sebastien Ros’ post on TypeScript apphost in Aspire, and our updated samples on aspire.dev.

🎛️ Resource commands are getting way more useful

Resource commands are an underrated Aspire feature, and one of my personal favorites for customizing the dev experience in my apps with Aspire. In 13.4, resource commands got way more powerful.

Commands can now declare typed arguments — labels, descriptions, defaults, allowed values, and validation — so a command can prompt for exactly what it needs in the same familiar Interaction Service we use for parameters and more in the dashboard and CLI.

Paired with 13.3’s command results feature, which made commands return more than just success or failure, this gives you more control over what information gets surfaced and how. Commands can collect inputs, render complex markdown results in the dashboard, and become custom interactions between the developer and the app while they develop it.

A great example of the new command infrastructure landed in the updated Microsoft Foundry integration. You can send messages – a required command text input – directly to Foundry hosted AI agents and see all the response metadata right from the dashboard.

We even added a new type of command: WithProcessCommand(). So beyond codified functions and HTTP commands, you can expose local scripts, tools, and CLIs as resource commands straight from the apphost. Just like other commands, Aspire handles argument passing, output capture, and result mapping. No shell gymnastics required.

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

const builder = await createBuilder();
const cache = await builder.addRedis('cache');

await cache.withProcessCommand('node-version', 'Show Node.js version', {
  executablePath: 'node',
  arguments: ['--version'],
});

Commands are one of my favorite features because they turn Aspire into much more than just a fancy launcher or manifest. You can create an ergonomic, intuitive dev experience that ships as part of your app itself, not more config and README files and scripts, and anyone on your team can use it from whatever IDE, browser, or coding agent they want.

🚢 Kubernetes and AKS keep swimming along

13.3 was our “FINALLY! Kubernetes support!” release. 13.4 is where we’ve started building in the stuff that your real production apps need.

This release adds typed cert-manager support, Gateway API and Azure Application Gateway for Containers integration for AKS, arbitrary Kubernetes manifest resources, and support for installing external Helm charts as part of the deployment pipeline. Helm configuration also gets a cleaner WithHelm(...) surface instead of the older split setup.

The shift is from “sure, that works if you know your way around” to “yes, this is an expected first-class use case.” Real apps need routing, TLS, ingress, third-party charts, and the occasional raw Kubernetes escape hatch, and 13.4 lets you express all of that without dropping out of the app model.

If you want the full walkthrough, especially around exposing apps to the internet on AKS, the updated Kubernetes and AKS docs are worth a look.

🦫 Go got a lot of love

We formalized Go support in the apphost in 13.4. We graduated the Aspire.Hosting.Go integration from the Community Toolkit into the main repo. That includes the practical stuff you actually want day to day: go mod lifecycle helpers, and OTEL and health-check wiring. We also added native VS Code debugging support through Delve, so the experience of building, running, and debugging Go services inside an Aspire app is at parity with TypeScript, Python, and C#. Go (pun intended) try it out!

✨ More notable highlights

I don’t want this to turn into an infinite blog post, so here are a few honorable mentions:

• Microsoft Foundry support got more polish and support for hosted agents, including API alignment with the rest of Aspire, protocol selection, deployment fixes, and better environment variable handling.
• Bun support shipped as Aspire.Hosting.Bun.
• The dashboard now has an AI Agents entry point to help you connect coding agents to your Aspire apps.
• NATS client registration got nicer for typed publish/subscribe scenarios.
• aspire logs and aspire otel now support --search, with the search happening server-side before anything streams back. Less noise, fewer tokens burned, and a much faster path to the line you actually care about.
• aspire doctor now surfaces version information more clearly, so SDK and CLI mismatches are easy to spot before they turn into a weird afternoon.

Again — if you want the exhaustive tour, the full What’s New in Aspire 13.4 has all of it, including the migration notes and breaking changes.

💫 Try it out today

aspire update --self
aspire update

New to Aspire? Head to get.aspire.dev to install the CLI to get started, and don’t forget to try the Aspireify skill for existing apps.

Already building with Aspire? Upgrade, take the new TypeScript apphost or Bun + Go integrations for a spin, wire up a process command or two, and tell us what feels good. We’re still iterating fast, and your feedback is how we decide what to build next.

Share feedback on GitHub, hang out with us on Discord, follow @aspiredotdev on X, or find us on BlueSky.

Happy Aspirifying! 💫