{"id":397,"date":"2026-05-07T10:00:00","date_gmt":"2026-05-07T17:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/aspire\/?p=397"},"modified":"2026-06-01T14:25:43","modified_gmt":"2026-06-01T21:25:43","slug":"whats-new-aspire-13-3","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/aspire\/whats-new-aspire-13-3\/","title":{"rendered":"What&#8217;s New in Aspire 13.3"},"content":{"rendered":"<p>Aspire 13.3 is here, and even though it&#8217;s only been five weeks since\n13.2, this one is packed.<\/p>\n<p>We have the new Aspireify skill for agent-assisted onboarding. We have\ncommand results that bring structured output from resource commands into\nthe dashboard, CLI, MCP tools, and integrations. We have browser logs,\nnetwork capture, and screenshots flowing into Aspire. And FINALLY, we\nhave first-class Kubernetes and <a href=\"https:\/\/learn.microsoft.com\/azure\/aks\/\">AKS<\/a> deployment support with Helm.<\/p>\n<p>This release includes 45 new features, 134 improvements, and 93 bug\nfixes across the AppHost, CLI, dashboard, extensions, and integrations.\nThat&#8217;s a lot! If you want every single detail, head to the full\n<a href=\"https:\/\/aspire.dev\/whats-new\/aspire-13-3\/\">What&#8217;s New in Aspire 13.3<\/a>.\nFor now, let&#8217;s look at some of my faves.<\/p>\n<p><div  class=\"d-flex justify-content-center\"><a class=\"cta_button_link btn-primary mb-24\" href=\"https:\/\/get.aspire.dev\" target=\"_blank\">Get Aspire 13.3<\/a><\/div><\/p>\n<p><iframe width=\"800\" height=\"450\" src=\"https:\/\/www.youtube.com\/embed\/Gn9BYmtr_m0?si=zbsUotn5ubwpRw0u\" allowfullscreen><\/iframe><\/p>\n<h2>\ud83d\udcab Aspireify anything<\/h2>\n<p>One of my favorite things about Aspire is how quickly it can make an\nexisting app feel less like a pile of processes and more like a real\nsystem. But anyone who has watched an\n<a href=\"https:\/\/www.youtube.com\/playlist?list=PLSi5JsxQ5oNsxyJk2HRBI35S0862vElfg\">AspiriFridays<\/a>\nstream knows that aspirification takes real work. We&#8217;ve spent almost a\nyear adding Aspire to community apps live on Fridays, and every app has\nits own little personality.<\/p>\n<p>What services are in here? Which ports matter? Which environment\nvariables are real dependencies? Which Docker Compose services should map\nto first-party Aspire integrations? What looks like &#8220;just add an\nAppHost&#8221; is actually a lot of careful repo archaeology, a lot of &#8220;wait,\nwhy does this service need <em>that<\/em>?&#8221;, and a lot of tiny decisions that\nmake the final Aspire experience feel good.<\/p>\n<p>That is exactly what the new <strong>Aspireify<\/strong> skill is for.<\/p>\n<p>When <code>aspire init<\/code> drops a skeleton AppHost into an existing app, the\nnew Aspireify skill gives your coding agent a guided workflow for finishing\nthe job. It is a one-time setup skill that helps the agent inspect the\nrepo, understand how the app already runs, and wire the AppHost to fit\nthe app instead of forcing the app to fit Aspire.<\/p>\n<p>That last part is important. The default stance is &#8220;minimize changes to\nthe user&#8217;s code.&#8221; If your app already reads <code>DATABASE_URL<\/code>, the agent can\nmap that with <code>WithEnvironment()<\/code> instead of asking you to rewrite your\nconfiguration. If a port is hardcoded, the skill tells the agent when to\npreserve it and when to ask if Aspire should manage it. If Docker Compose\nalready exists, the agent maps what is there before trying to get clever.<\/p>\n<p>This is the kind of agent workflow I get excited about: source-aware,\ncompiler-checked, and opinionated about asking when there is a real\ntradeoff. After the repo is Aspireified, the regular Aspire skill takes\nover for day-to-day AppHost work like starting resources, checking logs,\nand debugging.<\/p>\n<p>Don&#8217;t worry, we still have plenty of ideas and side quests for\nAspiriFridays, even if an agent helps us out along the way.<\/p>\n<h2>\ud83d\udd14 Command results are more than just a boolean<\/h2>\n<p>Resource commands are one of those features that sound small until you\nuse them a lot. Being able to click a dashboard command or run a CLI\ncommand against a resource is great, but success\/failure is only the\nstart. Sometimes the whole point of the command is the output.<\/p>\n<p>In Aspire 13.3, resource commands can return structured results back to\nthe caller. Text and JSON results now flow through the model, gRPC,\nbackchannel, dashboard UI, CLI, and MCP tools. That means commands can\nreturn rich, markdown-formatted responses, not just &#8220;yep, it ran.&#8221;<\/p>\n<p>If you watched Michael Cummings&#8217;\n<a href=\"https:\/\/aspire.dev\/aspireconf\/\">Beyond Telemetry: Supercharging DevEx with the Aspire Dashboard<\/a>\nsession at Aspire Conf, this fits right into that story. Resource\ncommands are one of the best ways to turn repeated local-dev chores into\nsafe, discoverable buttons and CLI commands. Command results make those\nbuttons much more useful.<\/p>\n<p>HTTP commands can return response bodies too, surfaced through the CLI,\ndashboard, and generated polyglot SDKs. The resource rebuild command now\nreturns build output as structured text data, so tools and agents can\nconsume the result directly without scraping resource logs.<\/p>\n<p>The dashboard ties this together with a new notification center in the\nheader. Command execution results show up as timestamped success\/failure\nnotifications with markdown rendering and a <strong>View response<\/strong> action for\nthe full output.<\/p>\n<p>This also makes Aspire integrations more extensible. Integrations can\nadd commands that return meaningful results instead of just changing\nstate somewhere in the background. I actually just opened a\n<a href=\"https:\/\/github.com\/microsoft\/aspire\/pull\/16842\">dev tunnels integration PR<\/a> for\n13.4 that uses this model to show tunnel URLs directly from the command\nresult. Very into this.<\/p>\n<h2>\ud83d\udc40 Browser logs give Aspire even more eyes<\/h2>\n<p>We always talk about Aspire giving agents eyes with logs, traces,\nmetrics, and resource state. So I guess this new capability is our&#8230; third eye?<\/p>\n<p>If your app has a frontend, a lot of the interesting failures happen in\nthe browser. Console errors, failed network requests, weird client-side\nexceptions, layout bugs that only show up after clicking three things in\nexactly the wrong order. This is another AspiriFridays special &#8211; Damian trying to tell me what button to click on the Network tab in browser developer tools.<\/p>\n<p>The new <code>WithBrowserLogs()<\/code> API attaches a tracked browser resource to\nany endpoint-capable resource. Aspire launches Chromium using a private\nCDP pipe instead of an exposed TCP debug endpoint, then streams console\nlogs, network requests, and errors into the resource log stream.<\/p>\n<pre><code class=\"language-csharp\">var frontend = builder.AddViteApp(\"frontend\", \"..\/frontend\")\n    .WithHttpEndpoint(port: 3000)\n    .WithBrowserLogs();<\/code><\/pre>\n<p>And in a TypeScript AppHost:<\/p>\n<pre><code class=\"language-typescript\">const frontend = await builder.addViteApp(\"frontend\", \"..\/frontend\")\n    .withHttpEndpoint({ port: 3000 })\n    .withBrowserLogs();<\/code><\/pre>\n<p>The implementation ships from the new <code>Aspire.Hosting.Browsers<\/code>\nprerelease package. A dashboard command lets you configure scope,\nbrowser, and user data mode at runtime, and a screenshot command saves\nPNGs as durable local artifacts.<\/p>\n<p>This is amazing for human debugging, and it is great for agent workflows\ntoo. Your agent can run the app, inspect browser logs, capture what\nchanged, fix the code, restart the resource, and keep going without\nasking you to paste screenshots back into chat. Build, run, observe,\nfix, rinse, repeat.<\/p>\n<h2>\ud83c\udf0d TypeScript AppHost is getting closer to GA<\/h2>\n<p>Aspire 13.2 brought TypeScript AppHost authoring, which was a huge step\ntoward making Aspire feel natural no matter what language you are\ncomfortable in. In 13.3, we kept pushing on that foundation.<\/p>\n<p>TypeScript, Python, and Java AppHosts now expose the complete set of\n<code>Aspire.Hosting<\/code> extension methods. If it works in C#, it should work\nfrom your language too: execution configuration, eventing, pipeline\nsteps, Docker Compose customization, Dockerfile building, and all the\nother bits that make an AppHost more than a startup script.<\/p>\n<p>We also spent time making the APIs feel idiomatic. Methods like\n<code>addProject<\/code>, <code>withEnvironment<\/code>, and <code>withReference<\/code> are consolidated so\nthey read naturally in each target language.<\/p>\n<p>Python joins as a new AppHost code generator, and Java AppHost support\nis much closer to the TypeScript experience with unions,\noptional\/nullability, callbacks, and a new <strong>Empty (Java AppHost)<\/strong>\nstarter template.<\/p>\n<p>If you want more on how TypeScript AppHost works under the covers, check\nout Sebastien Ros&#8217; post on\n<a href=\"https:\/\/devblogs.microsoft.com\/aspire\/aspire-typescript-apphost\/\">TypeScript AppHost in Aspire 13.2<\/a>\nand the <a href=\"https:\/\/aspire.dev\/app-host\/typescript-apphost\/\">TypeScript AppHost project structure<\/a>\ndocs. The short version: Aspire generates a typed SDK into <code>.modules\/<\/code>,\nyour <code>apphost.ts<\/code> imports from it, and the SDK regenerates when you add\nor update integrations.<\/p>\n<p>Also, shout-out to the new <code>ASPIREEXPORT013<\/code> analyzer diagnostic, which\ncatches duplicate capability IDs at build time. Agents love compilers,\nhumans love not finding out about generated SDK problems at runtime,\neverybody wins.<\/p>\n<h2>\u2638\ufe0f Kubernetes and AKS, finally!<\/h2>\n<p>By far the most asked-for Aspire deployment feature has been Kubernetes.\nAspire has had a really nice deployment story for Azure Container Apps\nand Docker Compose, but a lot of you are running Kubernetes in production\nand have been waiting for Aspire to meet you there.<\/p>\n<p>With 13.3, Kubernetes joins the party as a first-class deployment target.\nFINALLY.<\/p>\n<p>The new <code>Aspire.Hosting.Azure.Kubernetes<\/code> package adds\n<code>AddAzureKubernetesEnvironment()<\/code>, so you can define AKS clusters, node\npools, SKU tiers, private clusters, and Azure Container Insights right\nfrom your AppHost. <code>aspire deploy<\/code> uses Helm under the covers, and you\ncan configure namespace and release names with <code>WithHelm()<\/code>.<\/p>\n<pre><code class=\"language-csharp\">var aks = builder.AddAzureKubernetesEnvironment(\"prod-aks\")\n    .WithHelm();\n\nbuilder.AddCSharpApp(\"api\", \"..\/api\")\n    .PublishTo(aks);<\/code><\/pre>\n<p>And the same idea from a TypeScript AppHost:<\/p>\n<pre><code class=\"language-typescript\">const aks = await builder.addAzureKubernetesEnvironment(\"prod-aks\")\n    .withHelm();\n\nawait builder.addCsharpApp(\"api\", \"..\/api\")\n    .publishTo(aks);<\/code><\/pre>\n<p>You also get declarative Ingress and Gateway API routing with\n<code>AddIngress()<\/code> and <code>AddGateway()<\/code>, including route, TLS, hostname, and\nclass configuration. Gateway TLS can even auto-discover the controller\nassigned FQDN when you use <code>WithTls()<\/code> without <code>WithHostname()<\/code>.<\/p>\n<p>And when you are ready to tear things down, <code>aspire destroy<\/code> will run\n<code>helm uninstall<\/code> for Kubernetes deployments. No more half-manual cleanup\nscripts living in a README somewhere. We love to see it.<\/p>\n<p>We will have a deeper Kubernetes post soon, because there is a lot more\nto say here.<\/p>\n<h2>\ud83e\uddfa A grab bag of very good stuff<\/h2>\n<p>There is a lot more in 13.3 that is worth calling out, so let&#8217;s do a\nquick grab bag.<\/p>\n<p>EF Core migration management now lives directly in your AppHost with the\nnew <code>Aspire.Hosting.EntityFrameworkCore<\/code> package. Six commands show up in\nthe dashboard and CLI: Update Database, Drop Database, Reset Database,\nAdd Migration, Remove Migration, and Get Database Status. For local\ndevelopment, you can run migrations automatically when the AppHost starts.\nFor production, you can generate idempotent SQL scripts at publish time.<\/p>\n<p>Azure networking gets a bunch of love too: Azure Front Door, Network\nSecurity Perimeters, private endpoints for Azure OpenAI and Foundry,\nprivate ACR endpoints, and automatic HTTPS upgrades for App Service.\nFewer &#8220;now go configure the real production network in some totally\ndifferent place&#8221; moments.<\/p>\n<p>JavaScript publishing gets three new models:\n<code>PublishAsStaticWebsite()<\/code>, <code>PublishAsNodeServer()<\/code>, and\n<code>PublishAsNpmScript()<\/code>. There is also a dedicated <code>AddNextJsApp()<\/code>\nintegration with standalone output support and correctly configured\nDockerfiles. Because yes, your Next.js deployment should know it is a\nNext.js deployment.<\/p>\n<p>The CLI now detects <strong>Bun, Yarn, and pnpm<\/strong> from lockfiles and\n<code>package.json<\/code> metadata, then adapts install, run, and watch commands to\nyour toolchain automatically. I am legally required to say &#8220;it just\nworks&#8221; here, because that is exactly the goal.<\/p>\n<p>Other goodies:<\/p>\n<ul>\n<li><code>aspire destroy<\/code> tears down deployments across Azure Container Apps,\nApp Service, Kubernetes, and Docker Compose.<\/li>\n<li><code>aspire dashboard<\/code> launches a standalone dashboard without an AppHost,\nwith OTLP endpoints for external telemetry collection.<\/li>\n<li><code>aspire docs api<\/code> lets you browse Aspire API reference docs from the\nterminal with <code>list<\/code>, <code>search<\/code>, and <code>get<\/code>.<\/li>\n<li><code>--list-steps<\/code> previews pipeline steps before you run <code>aspire deploy<\/code>\nor <code>aspire publish<\/code>.<\/li>\n<li>Docker Compose deployments now support Podman through automatic\nruntime detection.<\/li>\n<li>The VS Code extension gets CodeLens and gutter icons in AppHost files,\na built-in Simple Browser for the dashboard, workspace auto-restore,\nand better resource state indicators.<\/li>\n<li>Durable Task Scheduler support for Azure Functions, RabbitMQ v7\npublisher and subscriber OpenTelemetry tracing, stable\n<code>Aspire.Microsoft.Azure.StackExchangeRedis<\/code>, and new Foundry models.<\/li>\n<\/ul>\n<h2>\u26a0\ufe0f A few breaking changes<\/h2>\n<p>There are a few breaking changes you should know about before upgrading,\nespecially if you are using early Kubernetes\/Docker Compose\/AKS startup\nhooks, emulator management endpoints, the dashboard MCP server, the\nPython starter template, or Azure network output names.<\/p>\n<p>The full\n<a href=\"https:\/\/github.com\/microsoft\/aspire\/wiki\/13.3-Change-log\">breaking changes section<\/a>\nhas the details and migration notes.<\/p>\n<h2>\ud83d\udcab Get started<\/h2>\n<p>Already using Aspire? Update the CLI:<\/p>\n<pre><code class=\"language-bash\">aspire update --self<\/code><\/pre>\n<p>New to Aspire? Head to <a href=\"https:\/\/get.aspire.dev\">get.aspire.dev<\/a> to\ninstall the CLI, then add Aspire to an existing app:<\/p>\n<pre><code class=\"language-bash\">aspire init<\/code><\/pre>\n<p><div  class=\"d-flex justify-content-center\"><a class=\"cta_button_link btn-primary mb-24\" href=\"https:\/\/aspire.dev\" target=\"_blank\">Get Started with Aspire<\/a><\/div><\/p>\n<p>We will publish deeper dives into some of the meatiest 13.3 features\nover the next few weeks, especially Aspireify, command results, browser\nlogs, and Kubernetes and AKS deployment.<\/p>\n<p>As always, we would love to hear what you think. Share feedback on\n<a href=\"https:\/\/github.com\/microsoft\/aspire\">GitHub<\/a>, join us on\n<a href=\"https:\/\/aka.ms\/aspire-discord\">Discord<\/a>, follow us on\n<a href=\"https:\/\/x.com\/aspiredotdev\">X<\/a>, or find us on\n<a href=\"https:\/\/bsky.app\/profile\/aspire.dev\">BlueSky<\/a>.<\/p>\n<p>Happy Aspirifying! \ud83d\udcab<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Aspire 13.3 is here with the Aspireify skill, command results, browser logs, Kubernetes and AKS deployment, and more.<\/p>\n","protected":false},"author":1965,"featured_media":401,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1,52],"tags":[25,26,9,10,11],"class_list":["post-397","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-aspire-category","category-releases","tag-net","tag-apphost","tag-aspire","tag-cli","tag-integrations"],"acf":[],"blog_post_summary":"<p>Aspire 13.3 is here with the Aspireify skill, command results, browser logs, Kubernetes and AKS deployment, and more.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/posts\/397","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/users\/1965"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/comments?post=397"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/posts\/397\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/media\/401"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/media?parent=397"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/categories?post=397"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/aspire\/wp-json\/wp\/v2\/tags?post=397"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}