Our Latest Aspirations (Roadmap) - 2026 -> 2027

[maddymontaquila]

Aspire Roadmap (2026 → 2027)

Hi everyone 💫

What a year! Since last July, 128 of you merged 3,191 pull requests, closed 2,277 issues, shipped 31 releases, and pushed Aspire past 6k ⭐stars⭐ on GitHub — shipping most of the vision we wrote down along the way: TypeScript AppHost, aspire publish, and aspire deploy all hit GA, Kubernetes/AKS deployment matured, and aspire agent + skills brought agentic workflows in the box. Thank you — for every issue, PR, stream, and bug report. 💜 (The Q2 2026 update recaps it all.)

Last year, the story was simple: Aspire is for any app in any language. This year, the story is about depth, not breadth. The apps you're building are bigger and more serious, and the way you build them has changed. Last year, AI was "spicy autocomplete". Now, agents are writing most of our code, CI/CD and infra demands have exploded, and your everyday loop has changed fundamentally. This year is about making Aspire ready for real distributed apps, and for the agents building them alongside you.

So, this year, three focus areas guide us there:

• 🔗 Agent-ready — Aspire is built for the agentic era: build agents and agentic workflows, use agents inside your dev/test loop, and make your app something agents can run, inspect, and reason about.
• 🏗️ Scales with your team — Aspire scales to real distributed apps: big graphs, many repos, serious testing, and production deployment.
• ⚙️ Built to ship — We're investing in our own foundations — releases, CI, and infrastructure — so Aspire reaches you faster, more reliably, and with higher quality.

⚠️ Disclaimer: This roadmap is directional, not a commitment. It reflects our current thinking and areas of active exploration, but plans may evolve as priorities shift, feedback is incorporated, or technical constraints emerge.

🧑‍💻 Local Developer Experience

This is where we start. Aspire already orchestrates big, real distributed apps — this year we refine that experience until the size of your system stops being something you feel, iterating on a large app as fast as a single project, for you and the agents working alongside you.

• Start only what you need — Launch groups bring up just the slice of the system you're working on.
• Change your app host without restarting — Reload AppHost changes live, so edits to your app model take effect without a full restart.
• Stop waiting on builds — Project Resource v2 moves .NET build coordination into the AppHost runtime, so the host starts without waiting on every project.
• One app across many repos — Multi-repo support composes an app spanning repositories and orchestrates multiple app hosts.
• Run on more container runtimes — Debug against the runtimes you actually use, including WSL containers on Windows and Apple's container framework.
• History that survives restarts — Dashboard state and telemetry persist across restarts and crashes, so you keep your loop's history.
• A CLI that feels fast — Performance work across the CLI you notice day to day.
• Agents work where you work — Go beyond logs and telemetry, giving an agent working through Aspire deeper debugging context from your running app.

🧪 Testing

Testing is the biggest gap left from last year's roadmap, and this year it's a priority. What we hear most — especially from teams onboarding large internal services — is the cold-start cost of booting the whole app just to run one test. The goal is simple: testing a distributed app should feel as fast and focused as testing a single piece of it.

• Run only what a test needs — Start just the slice of the app graph a test touches instead of booting the whole thing, via launch groups / conditional startup.
• Testing support for all languages — Bring end to end tests to all languages in a first-class way.
• Less waiting before tests start — Project Resource v2's build-coordination work cuts the wait before a test AppHost is ready.
• Real or mocked dependencies, ready fast — Stand up real or stubbed container dependencies that are easy to author and quick to run, with better reuse across runs.
• Watch tests as they run — A live dashboard shows service behavior in real time while your tests execute.
• Debug CI failures locally — Capture dashboard state from a CI run and replay it on your machine to find what broke.
• Coverage in your pipeline — Collect and report code coverage as part of the test run.

🌐 Polyglot

Polyglot is the baseline now — and agents make it matter more than ever. With an agent in your loop, you can reach for the right language for the job, not just the one your team already knows. This year, we widen the circle and deepen what's already there.

• More languages, first-class — First-class app-host authoring expands beyond C# and TypeScript to Python, Java, and Go.
• Rust goes first-party — Rust app host support graduates from the Community Toolkit into the first-party repo, shipped and supported like the rest.
• Samples that teach humans and agents — More quickstarts and end-to-end samples in every language, rich enough to give agents the guidance they need on typed config, connection wiring, and telemetry — the role client integrations used to play.
• Write integrations in any language — Use any language to author Aspire integrations for hosting your own services, containers, and other resources.

🛠 Tooling & Extensibility

Aspire is more powerful when others can build on it. This year we open up the CLI, the editor, and the integration ecosystem — for the community, for partners, and for the agents working through Aspire.

• Build on the platform — Extension points to let the community extend the Aspire Dashboard, CLI and VS Code experience, not just use them.
• Integrations beyond the box — Discover and add third-party integrations from the CLI with custom feeds, so the ecosystem isn't limited to the built-in Aspire.Hosting.* packages.

🔌 Integrations (incl. Hosting & Auth)

Aspire's integration catalog is how your app connects to the services it relies on — and that includes hosting and authentication, which live here alongside everything else. This year we keep growing the catalog and strengthen the integrations teams lean on most.

• First-class Entra ID — Stronger, built-in support for authenticating with Microsoft Entra ID.
• Bring your own auth with Keycloak — Continued support for Keycloak as an auth provider.
• A growing catalog — More integrations across the board, including new data integrations like Horizon DB.

🤖 AI Apps

Aspire isn't just agent-ready — it's where you build and ship the AI apps themselves: agent-based apps, the models behind them, and the services around them, deployed to platforms like Foundry.

• Build agent-based apps — A first-class environment for composing agent apps and the models, services, and data they depend on, with templates and command integrations to scaffold common scenarios fast.
• Host and deploy to Foundry — First-class hosting for models and agents, deployed to Azure AI Foundry alongside the rest of your app.
• Aspire in the Copilot canvas — Bring the Aspire app model into GitHub Copilot's app canvas.

🚀 Deployment

Deployment grew up this past year — aspire publish and aspire deploy are GA, Docker Compose is stable, and Kubernetes deployment advanced fast. This year is about making deployment real-app-ready: production-grade, repeatable, and wired into the pipelines teams already run.

• Pipelines that live with your app — Generate GitHub Actions and Azure DevOps pipelines straight from your app host, so your deployment definition travels with your app model.
• Every target, production-solid — Take the targets that shipped — Docker Compose, cloud-agnostic Kubernetes, Azure (App Service, Container Apps, etc) and AWS — to consistent, GA-level quality for real workloads, with Kubernetes in particular as a focus. We're also ready to tackle Terraform and exploring GCP to widen the map further.
• Real dev/stage/prod environments — Mature environment modeling with environment-scoped config, secrets, and outputs.

⚙️ Infra

Some of the most important work this year is on our side of the repo — the pipelines, tests, and infrastructure that get Aspire into your hands. The goal is simple: ship Aspire faster, more reliably, and with higher quality, release after release.

• Greener builds — Harden our build and test infrastructure so CI is trustworthy, flaky tests get squeezed out, and both team and community PRs can merge with confidence.
• One command away, everywhere — Keep Aspire a single command to install across NuGet, npm, Homebrew, and WinGet, with automated, readable release notes every time.
• Seamless updates — Move cleanly between channels (daily builds for the bleeding edge, stable for production, and PR builds for specific testing).
• Use Aspire to influence Aspire — Take the learnings we have from building, shipping, and delivering Aspire, and use those to shape new features and experiences for you!

📚 Content & Community

• aspire.dev — Official docs, samples, and walkthroughs.
• YouTube — Demos, deep dives, and livestream replays.
• Aspire Conf 2026 — Catch every session on the Aspire Conf playlist.
• Follow along — Bluesky · X · Twitch · Discord

---

That's the year ahead: agent-ready, scaling with your team, and built to ship. Three bets, one goal — Aspire for any app, in any language, from your first line of code to production. Strong defaults, polyglot by default, and built-in awareness of your infrastructure and runtime stay at the heart of it.

We plan in the open and keep adjusting as we learn from you. If you want to talk through any of it — or just say hi 👋 — come find us in the Aspire Discord. See you there!

— @joperezr, @maddymontaquila, @davidfowl, and the Aspire team

[tjwald]

Amazing work, and amazing roadmap! Looking forward to seeing it happen!

Pipelines that live with your app

Can this include gitlab? And also, what is the idea? Having a step that generates the pipelines, and then from there the pipeline runs as normal?

Terraform

Have you thought of how to support this? It is a complex integration × deployment support matrix.

Start only what you need

Will this include grouping resources and/or visualizations of groups of resources?

[maddymontaquila]

it should be generic enough that you could generate something gitlab-able, but we are starting with gh actions and maybe AzDO.

Terraform - have we thought about how? yes. do we have a solid plan? ehhh, we know it will take a lot of iteration, just like K8S!

Grouping - Ooh yeah, this would be a very natural extension of that. So, yes probably!

[phsbrown]

Awesome roadmap! Aspire is already great and it is getting better every day!

• More languages, first-class — First-class app-host authoring expands beyond C# and TypeScript to Python and Go.

Could this include Java as well? My current job has .net, java, some ts and a little bit of python. It would be easier to persuade everyone to use Aspire if it had AppHosts in all 4 languages.

[maddymontaquila]

Yes!!! java is def part of the plan - honestly just didn't list it out because we've shown the preview of it already. I'll edit!

[KennethHoff]

In a recent AspiriFriday someone showed an integration that allows you to define inline WebApplications — something along the lines of builder.AddInMemoryWebServer or something like it. They also clarified that this was (at least at the time) a C#-exclusive feature, which isn't ideal, but regardless; it's a really cool concept, being able to create mocks for third party services inline like that.

My question is; is that the general idea behind the Real or mocked dependencies, ready fast — [...] point? If not, would it be possible to support such a thing?

[davidfowl]

That's not something we plan to do, but it should be possible to build things like that using what is already there!