The Aspire Compiler

At the heart of Aspire is a resource model. It defines the shape of your application — its services, dependencies, configuration, and how everything connects. But this model doesn’t just describe intent; it runs in two distinct modes:

In runtime mode, Aspire acts as a local orchestrator. It executes your application model directly, standing up resources like processes, containers, and local emulations of cloud services. This is the developer inner loop: fast, iterative, and predictable. Resources behave like runtime entities with well-defined lifecycles. This lets developers model their app the same way whether they’re running everything locally or deploying to the cloud.

In publish mode, Aspire compiles the application model into artifacts you can hand off to a deployment pipeline. These include Kubernetes manifests, Terraform configs, Bicep/ARM templates, Docker Compose files, or CDK-based constructs.

In Aspire, the action is called publishing, and the units that perform this work are called publishers. But under the hood, the architecture closely mirrors a traditional compiler.

Lowering the Model

In a traditional compiler, you take a high-level programming language and lower it step by step:

• First into an intermediate representation (IR), which abstracts away language-specific features.
• Then into machine code, tailored to a specific CPU architecture.

Aspire does the same thing, but for applications:

• The application model is the high-level language.
• Aspire lowers this into intermediate constructs, which may or may not be target-specific (for example, CDK-style object graphs).
• Finally, a publisher emits the target runtime representation: the YAML, HCL, or JSON files your platform actually runs.

This layered approach lets Aspire do powerful things:

• Validate and enrich models during transformation
• Support multiple deployment targets
• Let users hook into each phase to customize behavior
• Keep the high-level model clean, expressive, and portable

And importantly, the translation process itself is extensible. You can define your own transformations, enrichments, and output formats, allowing Aspire to adapt to your unique infrastructure and deployment environments.

A Compiler for Application Topology

Most tools out there operate at one layer: either they run your app, or they deploy it. Aspire spans both.

We don’t just execute the app — we compile it. This gives us structure, separation of concerns, and the ability to build reusable publishing pipelines.

Want to inject annotations into every resource before deployment? Write a transform. Want to target a new environment like Nomad or Azure Container Apps? Write a publisher.

Just like compilers enable new languages to target new chips, Aspire enables new models to target new infrastructure.

Publish mode is still evolving, but this compiler-like architecture gives us a foundation to grow from. In the future, Aspire will:

• Enable fully declarative deployment workflows
• Support multiple publish targets out of the box
• Let teams build custom publishers and transforms for their internal platforms
• Bridge the gap between developer intent and production infrastructure

We’re building a compiler for application topology — one that treats your architecture as a first-class artifact.

Most tools give you a way to run your app. Aspire gives you a way to describe it — and then compile that description into something real.

This is how we bridge the gap between local dev and production, between intent and implementation.

This is the Aspire compiler.