Aspire Samples: a catalog of twenty-five working integrations, sorted by the problem you have rather than the stack you use

Five scenario tables, one repeated schema

Most sample collections are a flat list of directories. This one is a catalog, and the README is structured as five browse-by-scenario tables: full-stack JavaScript and TypeScript, polyglot full-stack, backend integrations by language, cloud, AI and event-driven, and .NET with frontend and platform.

Every table uses the same four columns beyond the sample name. Workload languages, AppHost, Deploy, and a one-line description. That consistency is the design decision here, and it does more work than any individual sample. A developer arriving with a specific problem can scan for the row that matches and get three pieces of information immediately: which languages are involved, how the orchestration is written, and what the intended deployment story is.

The polyglot table makes the point best. Polyglot Task Queue is React plus a Node API plus Python and C# workers coordinated through RabbitMQ. RAG Document Q&A is a Svelte frontend with a FastAPI backend, Qdrant and OpenAI. Vite plus C# plus PostgreSQL puts all three into a single Aspire app. These are the rows that demonstrate what Aspire is actually for, which is describing a multi-process application in one place rather than orchestrating a set of .NET services.

The catalog is also honest about its own scale. Roughly twenty-five sample directories sit under `samples/`, plus a `Directory.Build.props` and `global.json` at that level, which is what you would expect when a single MSBuild file has to apply to heterogeneous sub-solutions.

The AppHost column is the real architectural decision

Reading down the AppHost column, every sample uses one of two values: C# AppHost or TypeScript AppHost. That is the first thing to settle, because it determines how you express your application graph and how much of your stack has to be .NET to participate.

The C# AppHost samples lean toward mixed .NET scenarios. Integrating Frontend Apps puts React, Vue and Angular in front of a C# AppHost. Integrating Python Apps pairs a FastAPI backend with a React frontend and a C# AppHost. The Go integration builds a Gin app from a Dockerfile with a C# AppHost. The cloud samples, including Azure Functions and the Image Gallery with Blob, Queues, SQL and Container Apps Jobs, are all C# AppHost.

The TypeScript AppHost samples skew toward JavaScript-heavy work. Node plus Redis plus Vite, the Go API with chi, the Python FastAPI plus PostgreSQL CRUD app, and the MailDev and MailKit custom integrations all use a TypeScript AppHost, as do the polyglot rows. The Python Script sample is described as using a file-based AppHost, which is the lightest form in the collection.

What makes the TypeScript AppHost entries interesting for a .NET shop is the MailDev and MailKit row, which is about authoring custom hosting and client integrations against ATS-generated TypeScript APIs. That is a different activity from the others in the table: instead of wiring up an existing service you are extending the resource model itself. The Custom Aspire hosting resources sample covers the .NET version of the same idea.

So the practical reading of the column is that Aspire does not require you to write .NET to describe your app, but the samples that lean on .NET platform features still assume a C# AppHost.

The Deploy column separates demos from real infrastructure

The Deploy column takes exactly three values, and reading it changes what you should expect from a sample.

Run only means the sample is built to start on your machine with no packaging step. Integrating Frontend Apps is Run only, as is the Node.js Weather Explorer, a Leaflet map over an Express API with OpenTelemetry calling the external Open-Meteo service. Most of the .NET platform samples are Run only, including Aspire Shop, the health checks sample, the Orleans distributed actor sample, the database container sample covering PostgreSQL, MongoDB and SQL Server, and the volume mount persistence sample. Custom hosting resources is Run only too.

Docker Compose means the sample covers the container path, which is where YARP and Compose output become relevant. The Node plus Redis plus Vite sample is a good example: an Express API, a React and Vite frontend, and Redis, all behind YARP, deployed through Compose.

Azure means the sample reaches into managed services. Azure Functions integrates Functions, ASP.NET Core and Blazor. The Image Gallery uses Azure Blob, Queues, SQL and Container Apps Jobs, and it is the most infrastructure-heavy row in the catalog.

Two rows blur the line deliberately. HealthChecksUI is Docker Compose and demonstrates isolated health endpoints. Running EF Core Migrations is Run only even though migrations normally imply deployment, because the sample is about running migrations inside Aspire workflows, which is a local orchestration concern. That is a useful reminder that the column describes the sample's scope rather than the difficulty of the underlying problem.

What the repository infrastructure says about maintenance

The root tree is small and conventional for a Microsoft sample repository: `.azuredevops/`, `.config/`, `.devcontainer/`, `.github/`, `CODE_OF_CONDUCT.md`, `SECURITY.md`, `LICENSE`, an `es-metadata.yml`, a `nuget.config`, and then `build/`, `samples/` and `tests/`.

Two things stand out. There is a `tests/` directory at the root rather than only per-sample tests, which suggests the samples are validated centrally in CI rather than each one standing alone. And the `.devcontainer/` directory means the intended authoring environment is a container, which matters for a catalog spanning C#, TypeScript, Python and Go, since it pins toolchains that would otherwise have to be installed per sample.

The metadata is also worth noting. `es-metadata.yml` at the root is the kind of file an editor or IDE extension reads to understand the shape of a repository, and the `nuget.config` sits at the root to feed every sub-solution.

One inconsistency you will notice: the CI badge at the top of the README points at `dotnet/aspire-samples`, while the repository itself is `microsoft/aspire-samples`. Both the badge and the Aspire links section point at `dotnet/aspire-samples` and `github.com/dotnet/aspire`, so the project has moved organization while its own links were written for the older location. GitHub redirects handle that, which is why it works rather than breaks.

The maintenance picture overall: last pushed September 18, 2026, not archived, roughly 1,200 stars and 345 forks, no published releases, and 113 open issues. No releases is normal for a sample catalog. The open issue count is the number to keep an eye on, since 113 against 1,200 stars is a steady stream of broken-sample and framework-migration reports that individual maintainers absorb rather than triage centrally.

The disclaimer is the most operationally useful paragraph in the README

Sample repositories tend to either say nothing about production suitability or say nothing at all. This one is explicit. The README states that the sample applications are intended to illustrate individual concepts that may be helpful in understanding the underlying technology and its potential uses, and that they may not illustrate best practices for production environments. It goes further: the code is not intended for operational deployment, and users should not rely on the samples as a foundation for commercial or production use.

Rather than leave it there, it links out to the security guidance that would actually apply, covering ASP.NET Core security topics and Node.js security. That is the right structure for a disclaimer, since it converts a limitation into a pointer.

It is worth reading the same paragraph against the sample list. Aspire Shop is described as a distributed e-commerce sample demonstrating Aspire integration, and the repository separately points to eShop at `dotnet/eshop` as the actual reference application for a services-based eCommerce site on Aspire. The distinction is instructive: one is a sample inside this catalog, the other is a reference app maintained elsewhere. When a row calls itself a shop, check whether you are being handed a demo or a reference.

The MIT license covers the samples themselves, which makes them freely reusable, and the license is the one piece of the README that is unambiguous about intent rather than scope.

Choosing where to start

A workable approach is to pick by your actual question rather than by closest language match, because the samples are organized around scenarios for that reason.

If you are adding a frontend to an existing .NET application, Integrating Frontend Apps is the direct row, and Vite plus YARP Static Files covers the harder version where the frontend is served through YARP in both run and publish modes. If your frontend is React and you want a database in the same Aspire app, Vite plus C# plus PostgreSQL is the row that matches.

If you are introducing Aspire to a codebase that is not primarily .NET, the Go and Python rows are the interesting ones, since they show Aspire describing processes written in other languages. The Python FastAPI plus PostgreSQL sample wires a FastAPI CRUD API to PostgreSQL and pgAdmin, which is a complete local stack in one directory.

If you want to extend Aspire rather than use it, the two custom resource samples are the ones to read, MailDev and MailKit against ATS-generated TypeScript APIs on the TypeScript side and Custom Aspire hosting resources on the .NET side.

And if your interest is observability rather than application structure, the Custom Metrics Visualization sample collects and visualizes custom metrics with Prometheus and Grafana, while the Standalone Aspire dashboard sample runs the dashboard container against any OpenTelemetry source, which is the way to get the Aspire view over a system you did not build with Aspire at all.

Whichever row you pick, read the sample's own directory rather than the root README. The root gives you the map; the sample directory is where the working code lives.

Editorial conclusion

This repository is best treated as a decision aid rather than a tutorial collection, because the two columns the README repeats in every table are the ones that matter. AppHost tells you how much C# you are committing to, and Deploy tells you how far the sample goes before it stops being a local demo. Start with the closest match in the scenario tables and read its own README rather than the root one, then check the Deploy column against what you actually intend to build. Two constraints are worth holding onto. The root disclaimer states plainly that these samples illustrate individual concepts, may not show best practices for production, and are not intended for operational deployment, with pointers to the ASP.NET Core and Node.js security guidance for that. And the 113 open issues against roughly 1,200 stars mean individual samples do break as Aspire moves, so treat any specific sample as a snapshot of a fast-moving framework rather than a stable reference.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/aspire-samples on GitHub
4. Project website
5. README