Getting Started With .NET Aspire 13: Building and Deploying an App With PostgreSQL, Redis, and Docker Compose

.NET Aspire is an application framework for building observable, production-ready, cloud-native applications with .NET.
It provides a consistent way to manage your application's dependencies, configuration, and deployment.

Think of Aspire as a layer that sits on top of your application and orchestrates how everything works together.
It handles service discovery, configuration, health checks, and telemetry out of the box.

Starting from version 13, .NET Aspire was rebranded to Aspire and is now a multi-language application platform.

While Aspire continues to provide best-in-class support for .NET applications, version 13.0 brings support for Python and JavaScript.
It provides comprehensive support for running, debugging, and deploying applications written in these languages.

Today, I want to show you how to build and run a .NET application with Aspire 13 and .NET 10.

In this post, we will explore:

• Getting Started with Aspire 13
• Configuring PostgreSQL and Redis in Aspire
• Exploring Aspire Dashboard
• Configuring OpenTelemetry
• Deploying Aspire Application to Docker Compose

Let's dive in.

Getting Started with Aspire 13

I have built a product API that has the following integrations:

• PostgreSQL database
• HybridCache with Redis

To add Aspire to your project, we need to do the following steps:

Step 1:

Install the Aspire project templates:

dotnet new install Aspire.ProjectTemplates

Step 2:

Install the Aspire CLI:

dotnet tool install --global aspire.cli

Step 3:

Add the Aspire support for the Products.Api project in Visual Studio or Rider:

Aspire introduces two new project types to your solution:

• AppHost: The orchestrator that defines your application's architecture and dependencies.
• ServiceDefaults: Shared configuration and observability setup applied to all services.

By default, the AppHost project has the entry file name AppHost.cs with the following content:

var builder = DistributedApplication.CreateBuilder(args);

builder
    .AddProject<Projects.Products_Api>("products-api");

builder.Build().Run();

The only dependency declared in the AppHost project is Products.Api, which contains our Web API.

Step 4:

Install the following NuGet packages in the AppHost project:

dotnet add package Aspire.Hosting.PostgreSQL
dotnet add package Aspire.Hosting.Redis

Step 5:

Configure all the dependencies in the AppHost.cs:

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");

var postgres = builder.AddPostgres("postgres");

builder
    .AddProject<Projects.Products_Api>("products-api")
    .WithReference(cache)
    .WithReference(postgres);

builder.Build().Run();

The WithReference(cache) and WithReference(postgres) methods inject connection strings for Redis and PostgreSQL into the API project.
Aspire automatically sets environment variables that the API can read to connect to these resources.

Step 6:

Configure the connection strings in the Products.Api project to connect to the PostgreSQL database:

using Microsoft.EntityFrameworkCore;
using Products.Domain.Products;
using Products.Infrastructure.Database;
using Products.Infrastructure.Repositories;

namespace Microsoft.Extensions.DependencyInjection;

public static class HostDiExtensions
{
    private static IServiceCollection AddEfCore(
        this IServiceCollection services, 
        IConfiguration configuration)
    {
        var connectionString = configuration.GetConnectionString("postgres");

        services.AddDbContext<ProductDbContext>((_, options) =>
        {
            options.UseNpgsql(connectionString);
        });

        return services;
    }
}

The key part is configuration.GetConnectionString("postgres"). This reads the connection string that Aspire injected when we called WithReference(postgres) in AppHost.cs.
Aspire automatically sets an environment variable with the PostgreSQL connection string, and the configuration system reads it.

This way, you don't need to hardcode connection strings in appsettings.json or your own environment variables.

In this project, I use the regular EF Core NuGet packages for Npgsql:

• Microsoft.EntityFrameworkCore 10.0.0
• Microsoft.EntityFrameworkCore.Design 10.0.0
• Npgsql.EntityFrameworkCore.PostgreSQL 10.0.0

Step 7:

Configure the connection string in the Products.Api project to connect to the Redis cache:

public static IServiceCollection AddWebHostInfrastructure(
    this IServiceCollection services, 
    IConfiguration configuration)
{
    services.AddHybridCache(options =>
    {
        options.DefaultEntryOptions = new HybridCacheEntryOptions
        {
            Expiration = TimeSpan.FromMinutes(10),
            LocalCacheExpiration = TimeSpan.FromMinutes(10)
        };
    });

    return services;
}

private static IServiceCollection AddRedis(
    this IServiceCollection services, 
    IConfiguration configuration)
{
    var redisConnectionString = configuration.GetConnectionString("cache")!;

    services.AddMemoryCache();

    services
        .AddStackExchangeRedisCache(options =>
        {
            options.Configuration = redisConnectionString;
        });

    return services;
}

The AddHybridCache method registers HybridCache with default expiration settings.
The AddRedis method registers StackExchangeRedisCache as the L2 cache.

Just like with PostgreSQL, Aspire injects the Redis connection string via configuration.GetConnectionString("cache").

In this project, I use the following NuGet packages for Redis cache:

• Microsoft.Extensions.Caching.Hybrid 10.1.0
• Microsoft.Extensions.Caching.StackExchangeRedis 10.0.1

Step 8:

Let's run our application locally with Visual Studio or Rider:

Aspire dashboard

The Aspire dashboard opens automatically in your web browser (the port may vary). The dashboard shows:

• Resources - All running services (postgres, cache, products-api)
• Console logs - Real-time logs from each service
• Structured logs - Filterable and searchable logs
• Traces - Distributed traces across services
• Metrics - Performance metrics and health checks

The first run may take a few minutes while Docker pulls the container images. Subsequent runs will be much faster.

The dashboard shows all running services, their health status, logs, and distributed traces.

---

👉 Read the full article on my newsletter: https://antondevtips.com/blog/getting-started-with-dotnet-aspire-13-building-and-deploying-an-app