By the end of this session, you will be able to:

• Manage configuration across Development, Staging, and Production environments
• Explain the configuration provider order and predict which value wins
• Store secrets safely with dotnet user-secrets, environment variables, and a cloud vault
• Publish a .NET API with dotnet publish and run it outside Visual Studio
• Containerize the API with a multi-stage Dockerfile and run it with docker run
• Inject configuration into a container using the __ hierarchy separator

Your Task API must talk to a different database, log at a different level, and trust a different frontend origin in each environment — without recompiling.

The ASPNETCORE_ENVIRONMENT variable decides which appsettings.{Environment}.json is loaded. If it is not set, .NET assumes Production.

# Linux / macOS — current shell only
export ASPNETCORE_ENVIRONMENT=Production

# Windows — cmd.exe
set ASPNETCORE_ENVIRONMENT=Production

# Windows — PowerShell
$env:ASPNETCORE_ENVIRONMENT = "Production"

# One-off, without touching the shell at all
dotnet run --environment Staging

{
  "profiles": {
    "http": {
      "commandName": "Project",
      "applicationUrl": "http://localhost:5080",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "Staging": {
      "commandName": "Project",
      "applicationUrl": "http://localhost:5081",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Staging"
      }
    }
  }
}

// Flat value by colon-delimited path
var issuer = builder.Configuration["Jwt:Issuer"];

// Typed value with a fallback
var expiry = builder.Configuration.GetValue<int>("Jwt:ExpiryMinutes", 60);

// Connection strings have a dedicated helper
var connection = builder.Configuration.GetConnectionString("Default");

// Arrays bind to collections
var origins = builder.Configuration
    .GetSection("Cors:AllowedOrigins")
    .Get<string[]>() ?? Array.Empty<string>();

builder.Services.AddCors(options =>
    options.AddPolicy("Frontend", p => p.WithOrigins(origins)));

public class JwtOptions
{
    public const string SectionName = "Jwt";

    [Required] public string Issuer { get; set; } = string.Empty;
    [Required, MinLength(32)] public string Secret { get; set; } = string.Empty;
    [Range(5, 1440)] public int ExpiryMinutes { get; set; } = 60;
}

// Program.cs
builder.Services
    .AddOptions<JwtOptions>()
    .Bind(builder.Configuration.GetSection(JwtOptions.SectionName))
    .ValidateDataAnnotations()
    .ValidateOnStart();

// Anywhere in the app
public class TokenService(IOptions<JwtOptions> options)
{
    private readonly JwtOptions _jwt = options.Value;
}

Environment variable names cannot contain : on Linux, so .NET accepts __ (double underscore) as the hierarchy separator.

# Adds a UserSecretsId GUID to the .csproj
dotnet user-secrets init

# Store values — keys use the same colon syntax as appsettings.json
dotnet user-secrets set "Jwt:Secret" "my-dev-secret-key-32chars-minimum"
dotnet user-secrets set "ConnectionStrings:Default" "Host=localhost;Database=tasks_dev;Username=postgres;Password=dev"

# Inspect what is stored
dotnet user-secrets list

# Remove one key, or wipe them all
dotnet user-secrets remove "Jwt:Secret"
dotnet user-secrets clear

name: Deploy Task API
on:
  push:
    branches: [ main ]

jobs:
  publish:
    runs-on: ubuntu-latest
    env:
      ASPNETCORE_ENVIRONMENT: Production
      Jwt__Secret: ${{ secrets.JWT_SECRET }}
      ConnectionStrings__Default: ${{ secrets.DB_CONNECTION }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'
      - run: dotnet test --configuration Release
      - run: dotnet publish -c Release -o ./publish

# Framework-dependent build — needs the .NET runtime on the host
dotnet publish -c Release -o ./publish

# Run the published app (no Visual Studio, no SDK required)
dotnet ./publish/TaskManagerApi.Api.dll

# Or run the generated native launcher directly
./publish/TaskManagerApi.Api

# Self-contained — bundles the runtime, no install needed on the host
dotnet publish -c Release -r linux-x64 --self-contained true -o ./publish-linux

• Reproducibility. The image contains the OS libraries, the .NET runtime, and your app — "works on my machine" stops being an argument
• Isolation. Two APIs needing different runtime versions run side by side on the same host
• Portability. The same image runs on your laptop, in CI, and on any cloud that speaks OCI
• Fast startup. A container shares the host kernel — it boots in milliseconds, not the tens of seconds a virtual machine needs
• Declarative. The Dockerfile is the deployment documentation, and it is version controlled

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
EXPOSE 8080

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["TaskManagerApi.Api/TaskManagerApi.Api.csproj", "TaskManagerApi.Api/"]
RUN dotnet restore "TaskManagerApi.Api/TaskManagerApi.Api.csproj"
COPY . .
RUN dotnet publish "TaskManagerApi.Api/TaskManagerApi.Api.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "TaskManagerApi.Api.dll"]

# Build. The trailing dot is the build context, not a typo.
docker build -t task-manager-api .

# Run, mapping host port 8080 to container port 8080
docker run -p 8080:8080 \
  -e ASPNETCORE_ENVIRONMENT=Production \
  -e Jwt__Secret=my-production-secret \
  task-manager-api

# Detached, named, and removed automatically when stopped
docker run -d --rm --name tasks -p 8080:8080 task-manager-api

Environment variables are how a container receives configuration — and __ is how nested keys survive the trip.

services:
  api:
    build: .
    ports:
      - "8080:8080"
    environment:
      ASPNETCORE_ENVIRONMENT: Production
      ConnectionStrings__Default: "Host=db;Port=5432;Database=tasks;Username=postgres;Password=${DB_PASSWORD}"
      Jwt__Secret: "${JWT_SECRET}"
    depends_on:
      - db

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: "${DB_PASSWORD}"
    volumes:
      - tasks-data:/var/lib/postgresql/data

volumes:
  tasks-data:

builder.Services
    .AddHealthChecks()
    .AddDbContextCheck<TaskDbContext>("database");

var app = builder.Build();
app.MapHealthChecks("/health/live");
app.MapHealthChecks("/health/ready");

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:8080/health/live || exit 1

Twenty minutes, working on your Task Management API project:

Session 25 — Capstone Project Review

• Presenting your Task Management API end to end
• Walking through auth, versioning, pagination, error handling, and tests
• Demonstrating the API running from a container rather than from an IDE
• Peer review against the capstone checklist, and where to go after this course

Make your Task Management API fully deployable: environment-aware configuration, zero committed secrets, and a working container image. Add a short DEPLOYMENT.md with the exact commands to build and run it.

• appsettings.Production.json exists and overrides only what differs — log level, allowed CORS origins, and Swagger being off
• Every secret is read through configuration and supplied by dotnet user-secrets locally and -e variables in the container; none appears anywhere in Git
• A JwtOptions class bound with AddOptions, ValidateDataAnnotations, and ValidateOnStart, so a missing secret fails at startup
• A multi-stage Dockerfile plus .dockerignore; docker run -p 8080:8080 serves every endpoint
• DEPLOYMENT.md lists the required environment variables and the build and run commands verbatim