EVERYTHING
Aspire, which Microsoft describes as a code-first orchestration and observability layer for distributed applications, has undergone major expansion with the release of version 13.4. This update fundamentally changes how developers approach cross-language microservices by making TypeScript a first-class citizen within the core Aspire file, known as the AppHost.
According to Devclass, this evolution removes the previous requirement for .NET developers to use C# for the AppHost configuration. For TypeScript projects, the application is now configured via an apphost.mts code file that imports an Aspire module. This capability allows developers to model complex distributed systems using a single language stack.
Orchestrating Distributed Applications
Aspire functions as a development tool—it does not run in production. Instead, developers use the Aspire CLI (command line interface) to define and debug their application structure locally. The AppHost is responsible for assembling and configuring these distributed components. For example, by executing aspire add postgres, the AppHost automatically gains support for PostgreSQL. This single command enables several complex features:
- Adding a container image to run the database engine.
- Creating the necessary database instance.
- Injecting connection properties as environment variables into selected projects.
- Mounting data volumes outside the container.
- Adding health checks and telemetry to the Aspire dashboard.
The integrated Aspire dashboard is a crucial development feature that consumes OpenTelemetry data, allowing users to monitor application health and track metrics like memory usage.
Expanding Language Support and Deployment Targets
Beyond TypeScript, Aspire continues its push toward multi-language support. Python, Java, and Rust were previously supported, and 13.4 adds new AppHost APIs for Go and Bun. This expansion makes the platform highly versatile for modern development teams.
Furthermore, the update introduces critical enhancements for deployment readiness. The Aspire dashboard is primarily intended for local development but can be run standalone via a Docker image. For production environments, developers add targets to an Aspire project to enable commands like publish and deploy. These targets include Azure container apps, Azure App Service, Kubernetes, and Docker Compose.
The new features specifically target complex infrastructure needs. Aspire 13.4 adds robust support for Kubernetes deployment, including integration with cert-manager, Gateway API, manifest resources, and external Helm charts. This level of detail simplifies the transition from local development to production scaling.
Addressing Developer Experience Challenges
The project has historically faced challenges in clear communication regarding its purpose. James Newton-King, a principal software engineer at Microsoft working on Aspire, noted that "You don’t run Aspire in production. You develop your app with it locally and then deploy to the platform you want." Distinguished engineer David Fowler acknowledged the difficulty of articulating what Aspire is, adding that many impressions about its function are outdated due to how much the project has evolved.
Aspire originated from an experimental tool called Project Tye in May 2020. It represents a substantial effort by Microsoft to simplify and improve the developer experience for complex distributed applications. The current release solidifies this vision, making powerful orchestration accessible across diverse programming ecosystems while maintaining high standards of observability.