TypeScript devs no longer need to tangle with C# to use Aspire dev stack after Microsoft update

Aspire 13.4 matters less as a feature release than as a signal that Microsoft wants the tool to escape its .NET cradle. Making the TypeScript AppHost generally available removes the last major barrier for teams that build distributed systems in JavaScript-adjacent stacks but still need coordinated local orchestration, telemetry, and deployment wiring. The practical shift is that the application’s control plane can now live in the same language as the services it assembles, reducing translation overhead and making Aspire easier to evaluate outside a C#-centric workflow.

The mechanism is straightforward but consequential: the AppHost models the system, then uses commands such as add postgres to generate containers, databases, dashboards, health checks, telemetry, and environment-variable wiring. That matters because it turns infrastructure composition into code that is checked alongside the application instead of buried in ad hoc scripts. The broader update also expands the range of supported targets and resource commands, so practitioners get a more unified development and deployment path without mistaking Aspire for a runtime service.

Still, the release does not erase the project’s biggest limitation: Aspire is useful for development and deployment preparation, not as something to operate in production. Its value depends on whether teams accept that boundary and on whether Microsoft can keep widening support beyond the Azure-.NET association that has constrained adoption. Kubernetes improvements, new language APIs, and broader target support help, but the real test is whether Aspire becomes a generic orchestration layer or remains a sophisticated niche for Microsoft-aligned stacks.

---

Microsoft has released Aspire 13.4, with the key feature being general availability of the TypeScript AppHost, as well as new integrations for Go, Bun, Blazor and WebAssembly.

The company currently describes Aspire as a “code-first orchestration and observability layer for distributed applications” which makes it sound like some kind of service, but it is not. Developers use the Aspire CLI (command line interface) to model, develop and debug distributed applications, originally just for .NET, but now for a variety of languages, with TypeScript now first-class so that even the core Aspire file, called the AppHost, can be written in the language. Aspire can also deploy applications, though it is not a service that runs in production. Instead, developers add targets to an Aspire project to enable commands including publish, which builds the artifacts to be deployed, and deploy, which deploys the artifacts to the configured target, such as Azure container apps, Azure app service or Kubernetes. Other targets include Docker Compose, AWS services, and others via third-party integrations. The AppHost in the .NET variant is a C# project and for TypeScript, a code file called apphost.mts which imports an Aspire module. The AppHost configures and assembles the distributed application. For example, by running aspire add postgres the AppHost gains the ability to add PostgreSQL support with a few lines of code, including options to add a container image to run the database engine, creating a database, adding a web-based admin dashboard, mounting a data volume outside the container, adding health checks and telemetry for the database server to the Aspire dashboard, and injecting connection properties as environment variables to selected projects. The Aspire dashboard is a development feature that consumes OpenTelemetry data to monitor the health of a running application and show data such as memory usage. It is not primarily intended for use in production but can be run standalone or even used in environments which do not otherwise use Aspire, available in a Docker image. Aspire 13.4 adds critical features for Kubernetes deployment, including support for cert-manager, Gateway API, manifest resources and external Helm charts. There are also enhanced resource commands, which execute commands exposed by resources in a running AppHost, and new AppHost APIs for Go and Bun, so that applications using these can be added. Python, Java and Rust were already supported. A new aspire-skills bundle is provided for AI agents. The full list of new features is here. Aspire was first released in 2024 but its roots go back further, to an experimental tool called Project Tye that appeared in May 2020. It is a bold effort to simplify and improve the developer experience for distributed applications, though held back from wider adoption by its .NET and Azure flavor, which Microsoft is now attempting to broaden. Another issue is that articulating what Aspire is has proved difficult, leading to questions like, why not use Aspire in production? “You don’t run Aspire in production. You develop your app with it locally and then deploy to the platform you want,” said James Newton-King, a principal software engineer at Microsoft working on the project. Distinguished engineer David Fowler acknowledged the communicating exactly what the project is has been difficult and added that “lots of the impressions about what Aspire is and how it worked is outdated because it’s changed so much.”