Aspire 13.3 is here, and even though it’s only been five weeks since 13.2, this one is still packed.
We have the new Aspireify skill for agent-assisted onboarding. We have command results that bring structured output from resource commands into the dashboard, CLI, MCP tools, and integrations. We have browser logs, network capture, and screenshots flowing into Aspire. And FINALLY, we have first-class Kubernetes and AKS deployment support with Helm.
This release includes 45 new features, 134 improvements, and 93 bug fixes across the AppHost, CLI, dashboard, extensions, and integrations. That’s a lot! If you want every single detail, head to the full What’s New in Aspire 13.3. For now, let’s look at some of my faves.
Aspireify anything
One of my favorite things about Aspire is how quickly it can make an existing app feel less like a pile of processes and more like a real system. But anyone who has watched an AspiriFridays stream knows that aspirification takes real work. We’ve spent almost a year adding Aspire to community apps live on Fridays, and every app has its own little personality.
What services are in here? Which ports matter? Which environment variables are real dependencies? Which Docker Compose services should map to first-party Aspire integrations? What looks like “just add an AppHost” is actually a lot of careful repo archaeology, a lot of “wait, why does this service need that?”, and a lot of tiny decisions that make the final Aspire experience feel good.
That is exactly what the new Aspireify skill is for.
When aspire init drops a skeleton AppHost into an existing app, the new Aspireify skill gives your coding agent a guided workflow for finishing the job. It is a one-time setup skill that helps the agent inspect the repo, understand how the app already runs, and wire the AppHost to fit the app instead of forcing the app to fit Aspire.
That last part is important. The default stance is “minimize changes to the user’s code.” If your app already reads DATABASE_URL, the agent can map 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 and when to ask if Aspire should manage it. If Docker Compose already exists, the agent maps what is there before trying to get clever.
This is the kind of agent workflow I get excited about: source-aware, compiler-checked, and opinionated about asking when there is a real tradeoff. After the repo is Aspireified, the regular Aspire skill takes over for day-to-day AppHost work like starting resources, checking logs, and debugging.
Don’t worry, we still have plenty of ideas and side quests for AspiriFridays, even if an agent helps us out along the way.
Command results are more than just a boolean
Resource commands are one of those features that sound small until you use them a lot. Being able to click a dashboard command or run a CLI command against a resource is great, but success/failure is only the start. Sometimes the whole point of the command is the output.
In Aspire 13.3, resource commands can return structured results back to the caller. Text and JSON results now flow through the model, gRPC, backchannel, dashboard UI, CLI, and MCP tools. That means commands can return rich, markdown-formatted responses, not just “yep, it ran.”
If you watched Michael Cummings’ Beyond Telemetry: Supercharging DevEx with the Aspire Dashboard session at Aspire Conf, this fits right into that story. Resource commands are one of the best ways to turn repeated local-dev chores into safe, discoverable buttons and CLI commands. Command results make those buttons much more useful.
HTTP commands can return response bodies too, surfaced through the CLI, dashboard, and generated polyglot SDKs. The resource rebuild command now returns build output as structured text data, so tools and agents can consume the result directly without scraping resource logs.
The dashboard ties this together with a new notification center in the header. Command execution results show up as timestamped success/failure notifications with markdown rendering and a View response action for the full output.
This also makes Aspire integrations more extensible. Integrations can add commands that return meaningful results instead of just changing state somewhere in the background. I actually just opened a dev tunnels integration PR for 13.4 that uses this model to show tunnel URLs directly from the command result. Very into this.
Browser logs give Aspire even more eyes
We always talk about Aspire giving agents eyes with logs, traces, metrics, and resource state. So I guess this new capability is our… third eye?
If your app has a frontend, a lot of the interesting failures happen in the browser. Console errors, failed network requests, weird client-side exceptions, layout bugs that only show up after clicking three things in exactly the wrong order. This is another AspiriFridays special – Damian trying to tell me what button to click on the Network tab in browser developer tools.
The new WithBrowserLogs() API attaches a tracked browser resource to any endpoint-capable resource. Aspire launches Chromium using a private CDP pipe instead of an exposed TCP debug endpoint, then streams console logs, network requests, and errors into the resource log stream.
var frontend = builder.AddViteApp("frontend", "../frontend")
.WithHttpEndpoint(port: 3000)
.WithBrowserLogs();
And in a TypeScript AppHost:
const frontend = await builder.addViteApp("frontend", "../frontend")
.withHttpEndpoint({ port: 3000 })
.withBrowserLogs();
The implementation ships from the new Aspire.Hosting.Browsers prerelease package. A dashboard command lets you configure scope, browser, and user data mode at runtime, and a screenshot command saves PNGs as durable local artifacts.
This is amazing for human debugging, and it is great for agent workflows too. Your agent can run the app, inspect browser logs, capture what changed, fix the code, restart the resource, and keep going without asking you to paste screenshots back into chat. Build, run, observe, fix, rinse, repeat.
TypeScript AppHost is getting closer to GA
Aspire 13.2 brought TypeScript AppHost authoring, which was a huge step toward making Aspire feel natural no matter what language you are comfortable in. In 13.3, we kept pushing on that foundation.
TypeScript, Python, and Java AppHosts now expose the complete set of Aspire.Hosting extension methods. If it works in C#, it should work from your language too: execution configuration, eventing, pipeline steps, Docker Compose customization, Dockerfile building, and all the other bits that make an AppHost more than a startup script.
We also spent time making the APIs feel idiomatic. Methods like addProject, withEnvironment, and withReference are consolidated so they read naturally in each target language.
Python joins as a new AppHost code generator, and Java AppHost support is much closer to the TypeScript experience with unions, optional/nullability, callbacks, and a new Empty (Java AppHost) starter template.
If you want more on how TypeScript AppHost works under the covers, check out Sebastien Ros’ post on TypeScript AppHost in Aspire 13.2 and the TypeScript AppHost project structure docs. The short version: Aspire generates a typed SDK into .modules/, your apphost.ts imports from it, and the SDK regenerates when you add or update integrations.
Also, shout-out to the new ASPIREEXPORT013 analyzer diagnostic, which catches duplicate capability IDs at build time. Agents love compilers, humans love not finding out about generated SDK problems at runtime, everybody wins.
Kubernetes and AKS, finally!
By far the most asked-for Aspire deployment feature has been Kubernetes. Aspire has had a really nice deployment story for Azure Container Apps and Docker Compose, but a lot of you are running Kubernetes in production and have been waiting for Aspire to meet you there.
With 13.3, Kubernetes joins the party as a first-class deployment target. FINALLY.
The new Aspire.Hosting.Azure.Kubernetes package adds AddAzureKubernetesEnvironment(), so you can define AKS clusters, node pools, SKU tiers, private clusters, and Azure Container Insights right from your AppHost. aspire deploy uses Helm under the covers, and you can configure namespace and release names with WithHelm().
var aks = builder.AddAzureKubernetesEnvironment("prod-aks")
.WithHelm();
builder.AddCSharpApp("api", "../api")
.PublishTo(aks);
And the same idea from a TypeScript AppHost:
const aks = await builder.addAzureKubernetesEnvironment("prod-aks")
.withHelm();
await builder.addCsharpApp("api", "../api")
.publishTo(aks);
You also get declarative Ingress and Gateway API routing with AddIngress() and AddGateway(), including route, TLS, hostname, and class configuration. Gateway TLS can even auto-discover the controller assigned FQDN when you use WithTls() without WithHostname().
And when you are ready to tear things down, aspire destroy will run helm uninstall for Kubernetes deployments. No more half-manual cleanup scripts living in a README somewhere. We love to see it.
We will have a deeper Kubernetes post soon, because there is a lot more to say here.
A grab bag of very good stuff
There is a lot more in 13.3 that is worth calling out, so let’s do a quick grab bag.
EF Core migration management now lives directly in your AppHost with the new Aspire.Hosting.EntityFrameworkCore package. Six commands show up in the dashboard and CLI: Update Database, Drop Database, Reset Database, Add Migration, Remove Migration, and Get Database Status. For local development, you can run migrations automatically when the AppHost starts. For production, you can generate idempotent SQL scripts at publish time.
Azure networking gets a bunch of love too: Azure Front Door, Network Security Perimeters, private endpoints for Azure OpenAI and Foundry, private ACR endpoints, and automatic HTTPS upgrades for App Service. Fewer “now go configure the real production network in some totally different place” moments.
JavaScript publishing gets three new models: PublishAsStaticWebsite(), PublishAsNodeServer(), and PublishAsNpmScript(). There is also a dedicated AddNextJsApp() integration with standalone output support and correctly configured Dockerfiles. Because yes, your Next.js deployment should know it is a Next.js deployment.
The CLI now detects Bun, Yarn, and pnpm from lockfiles and package.json metadata, then adapts install, run, and watch commands to your toolchain automatically. I am legally required to say “it just works” here, because that is exactly the goal.
Other goodies:
aspire destroy tears down deployments across Azure Container Apps, App Service, Kubernetes, and Docker Compose.aspire dashboard launches a standalone dashboard without an AppHost, with OTLP endpoints for external telemetry collection.aspire docs api lets you browse Aspire API reference docs from the terminal with list, search, and get.--list-steps previews pipeline steps before you run aspire deploy or aspire publish.- Docker Compose deployments now support Podman through automatic runtime detection.
- The VS Code extension gets CodeLens and gutter icons in AppHost files, a built-in Simple Browser for the dashboard, workspace auto-restore, and better resource state indicators.
- Durable Task Scheduler support for Azure Functions, RabbitMQ v7 publisher and subscriber OpenTelemetry tracing, stable
Aspire.Microsoft.Azure.StackExchangeRedis, and new Foundry models.
A few breaking changes
There are a few breaking changes you should know about before upgrading, especially if you are using early Kubernetes/Docker Compose/AKS startup hooks, emulator management endpoints, the dashboard MCP server, the Python starter template, or Azure network output names.
The full breaking changes section has the details and migration notes.
Get started
Already using Aspire? Update the CLI:
aspire update --self
New to Aspire? Head to get.aspire.dev to install the CLI, then add Aspire to an existing app:
aspire init
We will publish deeper dives into some of the meatiest 13.3 features over the next few weeks, especially Aspireify, command results, browser logs, and Kubernetes and AKS deployment.
As always, we would love to hear what you think. Share feedback on GitHub, join us on Discord, follow us on X, or find us on BlueSky.
Happy Aspirifying!
The post What’s New in Aspire 13.3 appeared first on Aspire Blog.
Log in
