Microsoft Makes Aspire Usable Without Touching C# — TypeScript AppHost Now Fully Supported
Microsoft has shipped Aspire 13.4, and the headline feature is that TypeScript developers can now write the core AppHost configuration file in TypeScript, no C# required. That might sound minor, but it removes one of the more significant friction points for anyone outside the .NET ecosystem who wanted to give Aspire a serious look.
For the uninitiated, Aspire is best described as a local orchestration and observability toolkit for distributed applications. It is not a cloud service. There is no Aspire runtime running in your production environment. You use it during development to wire together services, databases, and containers, run them locally, and eventually deploy the whole thing via configured targets like Azure Container Apps, Kubernetes, Docker Compose, or AWS. Think of it as a structured way to manage the chaos of multi-service development, with a built-in dashboard that ingests OpenTelemetry data so you can actually see what is happening across your running stack.
The AppHost is the central piece. It is the configuration file that defines your distributed application, what services exist, how they connect, and what infrastructure they need. In the .NET version this is a C# project. As of 13.4, TypeScript developers get a first-class equivalent, an `apphost.mts` file that imports an Aspire module and does the same job. Run `aspire add postgres` and you get PostgreSQL support scaffolded out, including container setup, database creation, an admin dashboard, health checks, telemetry integration, and connection strings injected as environment variables. Reasonably ergonomic.
The 13.4 release also adds AppHost APIs for Go and Bun, joining existing support for Python, Java, and Rust. There are new Kubernetes deployment features including cert-manager support, Gateway API integration, external Helm chart support, and manifest resources. Enhanced resource commands let you trigger actions exposed by resources in a running AppHost. There is also a new `aspire-skills` bundle aimed at AI agent tooling, because no release is complete without something AI-adjacent these days.
Aspire has an interesting history. Its roots trace back to Project Tye, an experimental developer tool Microsoft quietly launched in 2020. The project evolved considerably before landing as Aspire in 2024, and it has continued changing shape since. That ongoing evolution has created a persistent confusion problem. A lot of developers encountered early descriptions or outdated documentation and wrote it off as an Azure-centric .NET thing. Distinguished engineer David Fowler admitted as much, noting that much of the community's impression of what Aspire actually is reflects an earlier version of the project rather than what it has become.
The other persistent confusion is the production question. People see something that manages services, has a dashboard, and handles deployments, and naturally wonder why you would not just run it in production. The answer, as principal engineer James Newton-King has explained, is that you do not. You build and debug locally using Aspire, then deploy the outputs to whatever platform you are targeting. The Aspire dashboard can technically run standalone in Docker and has been used in non-Aspire environments, but that is not really the core use case.
Whether broadening language support will translate into broader adoption is an open question. The tooling is genuinely useful, but awareness remains low outside .NET circles, and the messaging has historically done it no favours. TypeScript support as a first-class citizen is a reasonable step toward fixing that.