If you have been tracking Aspire's release cadence, you already know the project moves fast. Version 13.2 introduced a preview TypeScript AppHost. Version 13.3 shipped native Kubernetes deployment with Helm. Now, three weeks and 519 pull requests later, Aspire 13.4 drops at Build 2026 with a headline feature that changes who can adopt Aspire: the TypeScript AppHost is generally available. You no longer need C# to orchestrate a distributed application with Aspire.

But that is not all. This release also adds first-class hosting integrations for Go and Bun, a preview Blazor WebAssembly integration, process-backed resource commands, persistent resource lifetimes, and a deeper Kubernetes deployment story with cert-manager and Gateway API support. It is the most polyglot Aspire release yet, and it is worth understanding what changed and what breaks.

TypeScript AppHost reaches general availability

The TypeScript AppHost was the most requested feature in the Aspire ecosystem, and for good reason. Aspire's orchestration model — defining resources, dependencies, and configuration in code — is powerful, but requiring C# for the AppHost file locked out teams that do not use .NET as their primary stack.

As of 13.4, TypeScript AppHosts are production-supported alongside C#. The scaffolding now generates an apphost.mts entry point (explicit ES modules rather than the ambiguous .ts extension), and the generated SDK modules live under .aspire/modules/ instead of the previous .modules/ directory. Startup validation runs before the application launches, so configuration mistakes surface at boot time rather than mid-run.

apphost.mts 
import { createAppHost } from "./.aspire/modules/apphost.gen.mjs";

const builder = await createAppHost();

const cache = builder.addRedis("cache");

const api = builder.addProject("api", "./src/Api/Api.csproj")
  .withReference(cache)
  .withHttpEndpoint({ port: 5100, env: "PORT" });

builder.addProject("web", "./src/Web/Web.csproj")
  .withReference(api)
  .withExternalHttpEndpoints();

await builder.build();

The TypeScript API mirrors C#'s fluent builder pattern with async method chaining. Documentation now includes TypeScript examples alongside C# for every feature, and the VS Code extension supports TypeScript AppHosts with the same CodeLens actions (Run, Stop, Restart, Open Dashboard) that C# projects get.

James Newton-King, Principal Software Engineer at Microsoft, made an important clarification alongside this release: "You don't run Aspire in production. You develop your app with it locally and then deploy to the platform you want." This distinction matters because the TypeScript AppHost is a development-time tool — it orchestrates your local dev environment and generates deployment manifests, but it does not ship with your application.

Go and Bun hosting integrations

Aspire 13.4 promotes the Go hosting integration from the Community Toolkit into the official Aspire.Hosting.Go package. The AddGoApp method orchestrates Go applications with a sensible development workflow: go run . during local development, and a generated Dockerfile with go build for deployment.

AppHost/Program.cs 
var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");

var api = builder.AddGoApp("api", "../api")
    .WithHttpEndpoint(port: 8080, env: "PORT")
    .WithReference(cache);

builder.AddProject<Projects.Web>("web")
    .WithReference(api)
    .WithExternalHttpEndpoints();

builder.Build().Run();

Build-time configuration like tags, ldflags, and gcflags is directly configurable, and the VS Code extension supports launching the Delve debugger for Go resources. OpenTelemetry wiring comes out of the box, so Go services send traces and logs to the Aspire dashboard without additional setup.

Bun support arrives via AddBunApp in the existing Aspire.Hosting.JavaScript package, giving teams using Bun the same orchestration and service discovery capabilities that Node.js applications already have.

Blazor WebAssembly hosting (preview)

The new Aspire.Hosting.Blazor package introduces a preview integration for standalone Blazor WebAssembly projects. This is notable because Blazor WASM applications are client-side — they run in the browser, not on a server. Aspire now models them as resources that participate in the structured lifecycle alongside server-side resources.

AppHost/Program.cs 
var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.Api>("api");

var gateway = builder.AddBlazorGateway("gateway")
    .WithReference(api);

builder.AddBlazorWasmProject("client", "../Client")
    .WithBlazorClientApp(gateway);

builder.Build().Run();

The integration enables Aspire service discovery from the Blazor WASM client and routes OpenTelemetry traces and logs to the Aspire dashboard. For teams building Blazor WASM frontends alongside API backends, this means one AppHost definition that models the entire stack.

// NOTE

The Blazor WASM integration is experimental and ships behind a preview flag. Expect API changes in subsequent releases.

Process-backed resource commands

Resource commands have existed since Aspire 13, but 13.4 introduces WithProcessCommand — a way to expose local scripts, tools, and CLIs as dashboard-clickable commands attached to a resource.

AppHost/Program.cs 
#pragma warning disable ASPIREPROCESSCOMMAND001
builder.AddRedis("cache")
    .WithProcessCommand(
        name: "redis-info",
        displayName: "Server Info",
        executablePath: "redis-cli",
        arguments: ["-h", "localhost", "INFO", "server"]);
#pragma warning restore ASPIREPROCESSCOMMAND001

When you click "Server Info" in the dashboard, Aspire executes the command, captures the output, and displays it inline. The API is experimental (hence the diagnostic suppression), but it solves a real workflow problem: running diagnostic commands against your local resources without switching to a terminal.

Commands also gained typed input arguments with labels, descriptions, defaults, and validation. This means you can build parameterised commands that prompt for values in the dashboard:

AppHost/Program.cs 
builder.AddPostgres("db")
    .WithCommand(
        name: "seed",
        displayName: "Seed Database",
        executeCommand: async context =>
        {
            var dataset = context.GetArgument<string>("dataset");
            // Run seeding logic...
            return CommandResults.Success();
        },
        configure: command =>
        {
            command.AddArgument("dataset", argument =>
            {
                argument.DisplayName = "Dataset";
                argument.IsRequired = true;
                argument.DefaultValue = "small";
            });
        });

A new ResourceCommandVisibility option controls whether commands appear in the dashboard, CLI, MCP interface, or all three.

Persistent resource lifetimes

This experimental feature lets resources survive AppHost restarts. Call WithPersistentLifetime() on a resource, and Aspire keeps it running when you stop and restart the AppHost — useful for databases, message brokers, or anything with startup overhead you do not want to pay on every code change.

AppHost/Program.cs 
builder.AddPostgres("db")
    .WithPersistentLifetime();

There are constraints: persistent resources use proxyless endpoints, require concrete ports for executables, do not support replicas, and conflict with IDE debugging sessions. It is a development ergonomics feature, not a production deployment model.

CLI improvements

The Aspire CLI continues to mature. The headline additions in 13.4:

aspire ls lists candidate AppHost projects in the current directory without starting one. Useful when a workspace contains multiple AppHosts and you need to know which is which.

aspire integration list and aspire integration search let you browse and search all available Aspire integrations from the terminal:

terminal 
aspire integration search redis
aspire integration list --category hosting

Search filtering for logs and telemetry now happens server-side. The --search flag on aspire logs and aspire otel supports field qualifiers like @http.status_code:500 and searches across message text, attributes, scope names, and trace IDs.

aspire doctor now reports the current CLI version, AppHost SDK version, all Aspire CLI installations on the machine (including shadowed or dotnet-tool installs), and whether updates are available.

Resource commands are now invoked from the CLI with named options rather than positional arguments:

terminal 
aspire resource cache seed-data --dataset small --force

Kubernetes deployment deepens

Building on 13.3's Helm support, this release adds three significant capabilities for Kubernetes-based deployments.

Cert-manager integration provides typed APIs for installing cert-manager, configuring ClusterIssuers (Let's Encrypt or custom ACME providers), and wiring TLS certificates to your resources. No more manually writing cert-manager YAML.

Gateway API and Azure Application Gateway for Containers support means AddAzureKubernetesEnvironment now provisions AGC ingress profiles and assigns the necessary Network Contributor roles automatically.

External Helm charts via AddHelmChart enable installing third-party charts as part of your Aspire deployment. The WithHelm(...) method consolidates chart name, version, release name, and namespace into a single configuration surface:

AppHost/Program.cs 
builder.AddKubernetesEnvironment("k8s")
    .WithHelm(helm =>
    {
        helm.ChartName = "prometheus-community/kube-prometheus-stack";
        helm.Version = "70.4.1";
        helm.ReleaseName = "monitoring";
        helm.Namespace = "observability";
    });

Dashboard updates

The dashboard gets a new AI Agents dialog accessible from the header, providing connection guidance for coding agents that interact with Aspire resources. It can be disabled via Dashboard:UI:DisableAgentHelp if your team does not use agent workflows.

Search across the dashboard now supports structured field qualifiers — status:error, @attr:value, negation, and numeric comparisons. The traces page gains duration filters and minimum span-duration filtering. Telemetry context limits have been raised significantly: 200 to 800 entries for traces, and 500 to 2,000 for console logs.

Resource dependency visualisation now shows waiting dependency details with clickable links, making it easier to trace why a resource has not started.

Breaking changes that matter

Aspire 13.4 carries ten breaking changes. The ones most likely to bite you:

Kubernetes routing renames. Ingress.WithRoute(...) becomes Ingress.WithPath(...), and routed endpoints must be external. If you are deploying to Kubernetes with custom ingress rules, expect a find-and-replace.

Helm configuration consolidation. Chart properties that were set individually now live inside WithHelm(...). Existing Kubernetes deployment code will need restructuring.

TypeScript SDK module path. Generated modules move from .modules/ to .aspire/modules/. Run aspire update --self before aspire update when upgrading TypeScript AppHosts from 13.3 to avoid code-generator failures.

RabbitMQ 4.3 default image. The default RabbitMQ image bumps from 4.2 to 4.3, which rejects transient non-exclusive queues by default. Pin a specific version with WithImageTag(...) if your application relies on the previous behaviour.

Keycloak HTTPS primary endpoint. When dev certificates are enabled, the primary endpoint switches to HTTPS. This affects token validity across restarts — tokens issued against HTTP URLs will not work against the HTTPS endpoint.

Foundry agent API changes. PublishAsHostedAgent becomes WithComputeEnvironment, and AddPromptAgent parameter ordering changes. If you are using Aspire with Microsoft Foundry hosted agents, review the migration notes carefully.

Common pitfalls

Upgrading TypeScript AppHosts in the wrong order. Always run aspire update --self to update the CLI first, then aspire update to update the AppHost. Reversing this order can cause the code generator to fail against the new module layout.

Persistent lifetimes and debugging. Persistent resources conflict with IDE debugging sessions because the debugger expects to control the process lifecycle. Disable persistent lifetimes on resources you need to debug, or use aspire attach instead.

WithProcessCommand diagnostic suppression. The API is experimental and requires suppressing ASPIREPROCESSCOMMAND001. It is tempting to suppress it globally — do not. Scope the suppression to the specific call site so you notice when the API stabilises or changes.

Assuming TypeScript AppHost parity. While the TypeScript API covers the core orchestration model, some features (particularly newer experimental ones) may land in C# first. Check the documentation for TypeScript coverage notes on features you depend on.

Summary