Aspire Integrations: Batteries included

Modern applications depend on many external services: databases, caches, message brokers, storage layers, observability tools, and sometimes AI systems. Each of these brings its own rules for configuration, connection strings, environment variables, authentication, and deployment. Setting all of this up usually takes a significant amount of time before any business logic is written.

Aspire offers a different experience.

It provides a batteries included approach through integrations. An integration describes how your application depends on an external service and how that service should be wired into local development, runtime configuration, and client code. Aspire handles the parts that developers normally repeat from project to project.

In Aspire, the integrations are the batteries. Some batteries are available in the core Aspire packages, many more come from the community. You can also add your own when you need something specific. You can see all exisiting integrations in the integrations gallery. Once connected, Aspire takes care of the cross-cutting tasks that usually slow developers down.

What are Aspire Integrations?

Integrations are Aspire’s way of connecting external services to an application in a consistent and predictable way. They fall into two groups, and both play an important role.

Hosting integrations

A hosting integration defines a resource. A resource represents something your application depends on, such as PostgreSQL, SQL Server, Redis, Kafka, Service Bus, Blob Storage, Elasticsearch, or AI models.

Hosting integrations allow Aspire to:

• Start local containers
• Assign ports and create endpoints
• Set credentials
• Shape connection details
• Publish environment variables
• Establish readiness and health rules
• Make tools like the Aspire dashboard aware of the service

Hosting integrations describe what your application needs, not how the application uses it.

Client integrations

Client integrations take the resource metadata and use it to configure your application code. They provide:

• A typed client library
• Automatic binding of connection details
• Access to environment variables
• Logging and tracing support
• Default retry and resilience behavior

Client integrations remove the repetitive setup code that most applications carry around. Hosting integrations configure the world. Client integrations let your app use that configuration.

Existing Hosting integrations

Aspire provides many hosting integrations. They cover a wide range of common dependencies, including databases like PostgreSQL, SQL Server, MySQL, Oracle, or MongoDB. They also include caching and storage systems such as Redis, Garnet, Blob Storage, and Table Storage. Messaging systems like Kafka, NATS, RabbitMQ, and Service Bus are supported as well. Aspire also has integrations for observability tools such as Seq or Elasticsearch and for AI runtimes such as OpenAI, Azure Foundry or GitHub models.

The important point is the fact that these integrations behave consistently. Each one defines a resource, shapes configuration, orchestrates local development, and exposes connection details that client integrations or custom code can consume.

These are the batteries that ship with Aspire. The ecosystem expands far beyond them.

The Aspire Community Toolkit

The Aspire Community Toolkit provides many more integrations and follows the same resource and binding conventions. It is available at:

Aspire Community Toolkit (https://github.com/CommunityToolkit/Aspire)

The toolkit includes integrations for databases, message brokers, observability tools, vector stores, AI systems, cloud emulators, and other components. It grows quickly and fills in areas that are not part of the main Aspire distribution.

Because the toolkit builds on the same extensibility model, its integrations work exactly like the built-in ones. If Aspire does not include a battery you need, the community often does. And if not, you can create one by following the same patterns.

The toolkit is owned and maintained by the Aspire community, and is easy to get involved in by contributing, reviewing PRs, opening issues, or updating docs!

How Hosting and Client integrations work together

The cooperation between hosting and client integrations is what gives Aspire its friction-free experience.

1. A hosting integration declares a resource

var db = builder.AddPostgres("catalog-db");

Aspire prepares everything needed for development and runtime.

2. Aspire generates environment variables

These variables contain values such as host, port, credentials, and shaped connection strings.

3. A client integration binds the configuration

services.AddNpgsqlDataSource("catalog-db");

The client integration uses the resource information to configure the client library. It also enables logging, tracing, and recommended default behavior.

4. The application requires no custom configuration

There is no need for custom connection-string building or environment-specific configuration files.

Eliminating connection-string ambiguity

Different drivers expect different connection formats. Some use URLs. Others use key/value pairs. Some require very specific parameters for TLS or authentication. Cloud services often add additional flags or routing information.

Hosting integrations in Aspire normalize these differences. They generate the correct details for dependent applications. When a client integration is used, it receives the properly shaped connection string for the specific driver.

But even when client integrations are not used directly the applications can rely on consistent individual connection properties available for any requirement like HOST, PORT, username and password, and so on.

These values can be used to create your own connection strings or passed into non-standard drivers. This also allows Aspire’s hosting integrations to work well with other languages, tools, or runtimes that might not yet have dedicated client integration packages. Aspire is polyglot.

Why Integrations save time

Integrations simplify development in several ways.

Configuration overhead is greatly reduced

Aspire computes wiring, credentials, and connection details automatically.

Observability comes for free

Client integrations provide tracing, metrics, and structured logging without additional setup.

Local development is easy

Running the AppHost starts the entire environment, including containers for required services.

Deployment workflows are smoother

A resource that binds to a local container during development can point to a managed cloud service in production without changing application code. Aspire hosting integration often shape-shift from local emulators or containers while developing to hosted managed services during deployment.

The model is flexible

Developers can use client integrations or rely on hosting integrations alone, depending on the language or stack.

Integrations as cross-cutting infrastructure

Integrations influence every part of an application’s lifecycle:

• Local development
• Hosting
• Client configuration
• Secrets and identity
• Deployment environments

Once a resource is introduced, it becomes part of a larger flow that helps the application throughout development and production.

Why Aspire’s extensibility model works

Resources describe intent. They do not lock you into specific infrastructure. Because of that, Aspire can add layers of behavior on top of resources:

• shaping connection properties
• orchestrating containers
• injecting environment variables
• attaching telemetry
• handling environment transitions

Integrations attach to this model in a consistent way. First-party, community, and custom implementations all benefit from the same foundation.

Adding more power with your own batteries

Aspire includes a strong set of batteries. The Aspire Community Toolkit adds many more. When you need something specific, you can create your own integration that fits naturally into the existing system.

Every new battery increases what Aspire can do without increasing complexity. Local development remains simple. Client wiring stays automatic. Telemetry continues to flow. Deployments remain predictable.

Aspire starts with batteries included. As your application grows, you add more batteries. The experience stays consistent and manageable.