Aspire 13.3: The Quality-of-Life Release We Needed

Aspire 13.3 is out, and while it may not be a headline-grabbing, paradigm-shifting release like Aspire 13 was, it is exactly the kind of release that makes day-to-day development noticeably better. If you work with Kubernetes, TypeScript AppHosts, or JavaScript frameworks, this release is going to feel like someone finally listened to your frustrations, because they clearly did.

Let me walk you through what’s new and what actually matters.

A Faster CLI Thanks to NativeAOT

This one is subtle but immediately noticeable. The Aspire CLI is now compiled as a NativeAOT .NET global tool targeting .NET 10. Previously it ran as a typical managed app with JIT startup overhead. Now it fires up essentially instantly.

If you run aspire run, aspire deploy, or aspire update dozens of times a day, you’ll feel this difference. It’s one of those small improvements that sounds boring on a feature list but makes you happy every single morning.

The `aspire dashboard` Command

Running the Aspire dashboard outside an actual AppHost used to be a bit of a chore. You’d pull a standalone container image, wire up ports, certificates, and OTLP endpoints by hand, and hope you hadn’t forgotten anything.

Aspire 13.3 introduces a proper aspire dashboard command that runs the dashboard in standalone mode: no Docker required, using the same binary as the SDK. It’s interactive and blocking, exposes dashboard and OTLP endpoints directly, and works perfectly for pointing any OTLP-emitting app (not just Aspire apps) at the dashboard to inspect logs, traces, and metrics.

This is especially useful when you want the observability benefits of the Aspire dashboard without committing to a full AppHost.

Finally: `aspire destroy`

This was a genuinely painful gap. You could aspire deploy to Azure, Kubernetes, or Docker Compose, but there was no first-class way to tear everything back down. You had to track resources by hand, dig through the portal, or write your own cleanup scripts.

Aspire 13.3 adds aspire destroy, and it works across all three compute environments:

Azure: tears down resources via ARM
Kubernetes: uninstalls Helm releases and namespaces
Docker Compose: stops and removes stacks

This is a huge quality-of-life win for ephemeral environments, feature branches, and preview deployments. Spin it up, test it, tear it down, without leaving orphaned resources in your subscription.

Container Tunnel Is Now On By Default

The container tunnel was introduced as an opt-in experimental feature back in Aspire 13.0. It lets containers consistently communicate with host-based services like the Aspire dashboard, an OTLP collector, or other projects, across Docker Desktop, Docker Engine on Linux, and Podman.

In 13.3 it’s enabled by default. No more per-environment hacks or relying on host.docker.internal (which only works on Docker Desktop anyway). If you need to opt out, set ASPIRE_ENABLE_CONTAINER_TUNNEL=false in your launchSettings.json.

Helm-Based Kubernetes Deployments

If you’ve ever tried to deploy an Aspire app to Kubernetes, you know how much glue code it required. Mixing Aspire with separate Helm charts, kustomize overlays, or hand-crafted YAML manifests was painful to set up and painful to maintain.

Aspire 13.3 introduces a batteries-included Helm-based deployment engine. You declare a Kubernetes environment in your AppHost using AddKubernetesEnvironment, run aspire deploy, and Aspire generates and applies a complete Helm chart end-to-end. aspire destroy cleans up the release and namespace when you’re done.

First-class Ingress and Gateway API routing comes along for the ride. Instead of hand-crafting YAML, you describe ingress behavior at the AppHost level and Aspire generates the appropriate Ingress, IngressClass, Gateway, HTTPRoute, and cert-manager Certificate resources. Typed, code-based, no raw YAML needed.

Heads up: Some routing types have moved namespaces compared to 13.2, so check your using directives if you referenced them directly.

TypeScript AppHost Parity: The Big One

This is probably the most impactful set of changes in 13.3 for anyone building polyglot apps with a TypeScript AppHost.

Unified `withEnvironment` API

All those withEnvironment* helpers (withEnvironmentExpression, withEnvironmentEndpoint, withEnvironmentParameter, withEnvironmentConnectionString, withEnvironmentFromOutput, withEnvironmentFromKeyVaultSecret) are now deprecated. They’re replaced by a single, unified withEnvironment(name, value) API that handles all of these cases.

This is a breaking change in spirit (you’ll get deprecation warnings), but it’s actually a relief. One consistent API rather than six slightly-different helpers.

Endpoint property expressions like endpoint.url, endpoint.host, and endpoint.port are now usable in TypeScript expressions too, which closes a long-standing gap with C# AppHosts.

Docker Compose Parity and More

TypeScript AppHosts in 13.3 now match C# across Docker Compose APIs, Azure Container Apps custom domain configuration, and YARP route helpers (addRoute, addCatchAllRoute). The WithDockerfileBuilder / AddDockerfileBuilder API is also now available in TypeScript, matching the C# WithDockerfile experience.

First-Class JavaScript Publishing

Publishing JavaScript and TypeScript apps used to mean hand-rolling Dockerfiles and figuring out the right approach for each framework. Aspire 13.3 introduces the PublishAs* family:

PublishAsStaticWebsite (preview): serves SPAs via a YARP static image
PublishAsNodeServer: for prebundled Node entry-points
PublishAsNpmScript: for SSR runtimes that execute npm scripts at runtime

There’s also a new AddNextJsApp helper that runs Next.js in development and configures standalone publishing automatically. As long as your next.config.js sets output: "standalone", you don’t even need an explicit PublishAs* call.

For Vite apps, AddViteApp handles development, and PublishAsStaticWebsite ships the production build as a YARP-served static site with an optional API reverse-proxy for consistent /api behavior between dev and production.

SSR frameworks like TanStack Start and SvelteKit can pair AddViteApp for dev with PublishAsNodeServer to ship a built Node server as a slim container, without copying node_modules at runtime. This is a significantly cleaner deployment story than what was possible before.

Bun, Yarn, and pnpm support in TypeScript AppHosts rounds this out nicely.

Dashboard: Notification Center and Rebuild Commands

The dashboard gets two very useful additions in 13.3.

The notification center (accessible via the bell icon) aggregates command results and lifecycle events in one place. When there are unread notifications a badge appears. Previously you had to scrape through log streams to find command output. Now it’s right there, and structured payloads from HTTP and resource commands show up cleanly.

Rebuild commands let you rebuild the image and restart a container or project resource directly from the dashboard, without restarting the whole AppHost. The result surfaces in the notification center. If you’re iterating on a Dockerfile or tweaking a service, this saves a lot of unnecessary full-AppHost restarts.

Browser Telemetry: Logs, Network Requests, and Screenshots

This one surprised me. The new Aspire.Hosting.Browsers integration captures browser console logs, network requests, and screenshots from frontend resources and surfaces them in the Aspire dashboard alongside server-side telemetry. Add WithBrowserLogs() to a frontend resource and Aspire becomes an end-to-end observability tool that covers both backend and browser behavior.

Combined with the Aspire MCP server and a tool like Playwright MCP, this creates a remarkably complete debugging loop without ever leaving your editor.

Azure Integrations

Aspire 13.3 adds several new Azure integrations worth knowing about.

Azure Front Door: AddAzureFrontDoor and WithOrigin let you provision a Front Door profile and attach backend origins through code rather than authoring ARM templates or clicking through the portal. The Standard SKU is provisioned by default, and ConfigureInfrastructure lets you attach WAF policies, enable caching, adjust SKUs, and more.

Network Security Perimeters: NSPs are now supported as a logical security boundary for Azure PaaS services like Storage, Key Vault, Cosmos DB, and SQL. Use Enforced mode to block rule violations, or Learning mode to log them without blocking, which is useful for audit-before-lockdown workflows.

AKS Hosting Integration: AddAzureKubernetesEnvironment gives AKS first-class treatment. Declare your AKS environment, customize node pools via WithSystemNodePool, and let Aspire generate a Bicep + Helm-based deployment pipeline. The control-plane SKU now defaults to Free, and AksSkuTier has been removed from the public API.

Private Endpoints: WithPrivateEndpoint now supports Azure Container Registry, Azure OpenAI, and Azure AI Foundry, extending private networking coverage for container image storage and AI services.

Azure AI Foundry Prompt Agent rework: The old AddAndPublishPromptAgent API and original AzurePromptAgentResource shape are gone. They never worked end-to-end anyway. They’ve been replaced with a new AddPromptAgent API that actually works. The Foundry model catalog also adds GPT-5.4 and Qwen3 VL.

Breaking Changes to Watch

A few things you need to fix when upgrading from 13.2:

--log-level becomes --pipeline-log-level on aspire publish and aspire deploy
NameOutput is renamed to NameOutputReference in Azure network resources
OtlpEndpointEnvironmentVariableName is removed
The dashboard MCP server and ASPIRE_DASHBOARD_MCP_ENDPOINT_URL are gone; use aspire agent init for AppHost-level MCP instead
AksSkuTier enum is removed
The JavaScript diagnostic ID ASPIREEXTENSION001 is renamed to ASPIREJAVASCRIPT001
dotnet new aspire-py-starter is removed; use aspire new aspire-py-starter instead
TypeScript withEnvironment* helpers are deprecated in favor of withEnvironment(name, value)
If you relied on package.json’s engines.node to pick Docker base images, you now need to specify Node versions explicitly in your Dockerfiles

Upgrading

The upgrade path is the same as always:

aspire update --self   # Update the CLI
aspire update          # Update projects in your repo

After that, audit the breaking changes above and re-run aspire agent init if you were using the old dashboard MCP server.

Wrapping Up

Aspire 13.3 is a solid quality-of-life release. No single feature is groundbreaking, but the sum of all the parts, including a faster CLI, a destroy command, Helm-based Kubernetes, TypeScript parity, browser telemetry, and cleaner JavaScript publishing, makes the overall experience meaningfully better.

If you’re building polyglot distributed apps with Aspire, this is a very worthwhile upgrade.

Stay up to date with Aspire at aspire.dev or join the Aspire Users group on LinkedIn.

Last modified on 2026-05-08