Configuration, environments & secrets

Understand the idea

Configuration lets the same application binary run in different environments. A development machine might use a local SQLite file, while a deployment uses a persistent volume and different logging settings. Those choices should not require editing source for every machine.

Secrets are a subset of configuration that need stronger handling. A connection string without credentials may be harmless to commit; one containing a password is not. Decide based on the value, not merely the filename.

Read named settings

TaskBoard reads ConnectionStrings:Board through GetConnectionString. The default appsettings file provides a local SQLite filename. The builder combines configured providers so later sources can override earlier ones.

Do not scatter literal connection strings across controllers. Register the context once using configuration, then let consumers depend on the configured context. A missing required production setting should fail clearly rather than silently selecting an unintended database.

var connection = builder.Configuration.GetConnectionString("Board")
    ?? "Data Source=taskboard.db";
builder.Services.AddDbContext<BoardDb>(options =>
    options.UseSqlite(connection));

Override values for a session

Environment variables use a double underscore to represent a nested configuration separator. In PowerShell, set ConnectionStrings__Board before running the process. The example below creates a separate development database file, which is useful for experimentation.

Remember that environment variables are process inputs. An already-running application generally will not inherit a variable you set later in a different terminal. Restart the process in the configured environment.

$env:ConnectionStrings__Board = "Data Source=taskboard-experiment.db"
dotnet run
# After stopping the app, clear this terminal override:
Remove-Item Env:ConnectionStrings__Board

Use development secret storage appropriately

dotnet user-secrets stores values outside the project directory for local development. It is a convenience for keeping secrets out of commits, not an encrypted production vault. Never print real secret values into logs or tutorial screenshots.

In production use your platform’s supported secret store or protected environment configuration, and grant the application only the access it needs. Rotate credentials that have been exposed; deleting them from the current file does not erase repository history.

dotnet user-secrets init
dotnet user-secrets set "Mail:ApiKey" "local-placeholder"
# This is a placeholder illustrating the workflow, not a real credential.

Keep environment behavior deliberate

Development enables helpful local behavior such as automatic migrations in this sample. Production enables exception handling and HSTS. Environment names should select controlled behavior, not hide unreviewed differences in business rules.

Launch settings apply to local tooling. They are not automatically deployed server settings. Test a published build with explicit environment configuration so you know which connection, logging level, and error behavior it actually uses.

{"ConnectionStrings":{"Board":"Data Source=taskboard.db"},"Logging":{"LogLevel":{"Default":"Information","Microsoft.AspNetCore":"Warning"}},"AllowedHosts":"*"}

When something doesn't work

A double underscore is the portable environment-variable separator; a single underscore does not mean nesting.

The working directory affects relative SQLite paths. Use an absolute persistent path in a deployment where process working directories may change.

User secrets are loaded by the development configuration workflow. Do not assume they will be present on a production server.