Aspire Community Toolkit: the integrations Aspire does not ship

Community contributed Aspire integrations, packaged like the first party ones

The Aspire Community Toolkit is described as a collection of integrations and extensions for developing with Aspire, and the repository holds the source code for it. The model is explicit in one sentence: all features are contributed by the community and maintained by a core set of maintainers.

That sentence is the whole proposition. Aspire's model is that an application description declares the services it depends on, and the tooling wires them together locally and in the cloud. Every service you want to model needs an integration, and the gap between what people actually run and what exists upstream is where this repository operates. The Bitwarden Secrets Manager client, the ChromaDB client, the GO Feature Flag client and the ActiveMQ hosting package are all things an application might need and might otherwise have to describe by hand.

The repository carries the .NET Foundation logo and a link to a FAQ at docs/faq.md for anyone who wants more of the story before reading the code.

Every integration ships as a stable and a preview NuGet package

The README leads with an autogenerated integrations table, and the table header tells you how the entries are structured.

| Package | Description |
| --- | --- |

Each row names a package, links to a Learn More README under src/ with the package folder name, and shows two NuGet packages: a stable one using the nuget/v badge and a preview one using the nuget/vpre badge. That double publishing is the mechanism that lets you try an integration before committing to it, and it is also the mechanism that tells you how much confidence the maintainers have in a given integration.

Looking at the entries that appear near the top of the table, the naming convention splits the collection in two. Packages prefixed with Hosting, such as Hosting.ActiveMQ, Hosting.Adminer, Hosting.Azure.Dapr, Hosting.Azure.Dapr.Redis and Hosting.Azure.DataApiBuilder, model a resource you run. Packages without that prefix, such as Bitwarden.SecretManager, Chroma, DuckDB.NET.Data and GoFeatureFlag, are client integrations for something you connect to.

Client integrations carry health checks, traces and telemetry

The difference between the two shapes shows up in what each package does for you. The Chroma package is described as a ChromaDB client that integrates with Aspire, including health checks, traces and metrics. The GoFeatureFlag package is a GO Feature Flag client that integrates with Aspire, including health checks, logging, and telemetry.

Both are clients, so what they add is observability of the connection rather than the ability to run the thing. When the container is up but the client is misconfigured, a health check that is wired into the Aspire dashboard is the difference between a five minute diagnosis and an afternoon.

The hosting packages do the other job. Hosting.ActiveMQ is a hosting package for hosting ActiveMQ, and Hosting.Adminer is a hosting integration for the Adminer database management container, which is the sort of tool a developer wants running next to a database during development and nowhere near production. Hosting.Azure.Dapr.Redis is more specific again: it configures Azure Cache for Redis as a Dapr state store or pub/sub component in your AppHost, which is a very particular claim about how a hosted resource is wired into the application model rather than merely started.

The examples directory is the part worth reading

The repository layout is more informative than the truncated table. The examples/ directory contains one folder per integration, and the list gives a good picture of the range the community has taken on: activemq, adminer, azure-ext, bitwarden-secret-manager, chromadb, dapr, data-api-builder, dbgate, dbx, deno, duckdb, elasticsearch-ext, flagd, floci, flyway, goff, java, javascript-ext, k3s, k6, keycloak-postgres, kind, kurrentdb and lavinmq.

Read that list as a map of what people actually wire into an Aspire application. There are databases and search engines, messaging brokers, feature flag systems, schema migration tools, Kubernetes distributions, load testing tools, and language runtimes such as deno and java. The topic tags on the repository list aspire, cloud, dotnet, golang, javascript, python and rust, which matches integrations that bring their own runtime clients into a .NET application model.

The rest of the tree shows the working practices of a modern .NET repository: a CommunityToolkit.Aspire.slnx solution file, Directory.Build.props and Directory.Build.targets, Directory.Packages.props for central package version management, a global.json pinning the SDK, a nuget.config, a dotnet-tools.json for local tooling, eng/ for engineering scripts, CODEOWNERS, a .devcontainer directory, and separate tests/ and tests-app-hosts/ directories. There are also agents/, AGENTS.md and a .mcp.json, which suggests the project has been set up for coding agents to work in the repository.

Where the community route differs from writing your own integration

The alternative to a community package is to write the integration yourself, inside your own repository, and version it on your own schedule. That option has real advantages. You own the code, you can shape the API to your application, and there is no coupling to the toolkit's release line.

The difference in approach is what the toolkit supplies. A community package arrives as a versioned NuGet package on the stable or the preview channel, with a README written for the Aspire model, an example application under examples/, and a place where health checks and telemetry follow a shared convention across many integrations. Writing it yourself means you write that integration, but you also write the documentation, the example, and the upgrade story for every Aspire version you move through.

The catch is the same in both directions. The toolkit's packages are versioned on the same 13.x line, so an Aspire major version bump is a coordinated upgrade for every dependency you took from it, and preview packages carry no stability promise. A team with many community packages accumulates that coupling quickly, which is the cost the toolkit does not remove.

Release cadence, licence and where the work sits

The release list shows v13.4.0 on 2026-06-02, v13.5.0 on 2026-08-25 and v13.6.0 on 2026-10-01, with the last push on 2026-10-18. The repository is not archived, so the toolkit is moving on a schedule roughly every two to three months, and the version numbers follow the Aspire major version rather than the toolkit having an independent numbering scheme.

That coupling is the single most important fact for an adopter. Your dependency on a community package is a dependency on the 13.x line, and when Aspire moves to 14, the community packages move with it, on the community's timing rather than the platform's.

The licence is MIT, with the terms in the LICENSE file at the repository root, which is the same permissive position most .NET community packages take, and it applies to the code in this repository. The individual integrations pull in third party clients such as DuckDB.NET.Data, so the licence terms of those transitive dependencies sit alongside it in your dependency tree.

On governance, the README is brief and points elsewhere. Features come from the community and are maintained by a core set of maintainers, CONTRIBUTING.md covers the contribution process, and CODEOWNERS records who owns which areas. For a team considering a dependency here, the practical question is not the licence but whether the integration you need has an active owner, and that is a question you can only answer from the repository itself.

Editorial conclusion

The toolkit suits an Aspire team that needs an integration the platform does not provide, and wants it packaged with the same conventions as the rest of the Aspire ecosystem rather than maintained in a private repository. It does not suit you if you need a guarantee of breaking change policy across Aspire major versions, since the packages track a 13.x line. Verify first which of the integrations you need exist in a stable build rather than only a preview one, and read the per package README linked from the integrations table before you take a dependency.

Frequently asked questions

Official sources

1. CommunityToolkit/Aspire on GitHub
2. License: MIT
3. Project website
4. README
5. Releases