Environments - Development, Staging, Production

Level: Beginner to Intermediate

ℹ️ Where This Fits

Environments help the same ASP.NET Core application behave differently while coding, testing, and running live for users.

ℹ️ What You'll Learn

• Three environments: Development (local coding), Staging (test servers), Production (live users)
• Development: Detailed error pages, hot reload, debug symbols, test data, minimal security
• Staging: Close to production, real database, real external APIs, test with actual configuration
• Production: Detailed errors hidden, performance optimized, security hardened, real user data
• ASPNETCORE_ENVIRONMENT variable: Sets current environment (Development, Staging, Production)
• app.Environment.IsDevelopment(): Conditional code: if Development, show detailed errors
• Environment-specific files: appsettings.Development.json vs appsettings.Production.json
• Database behavior by environment: Development uses test DB, Production uses real DB
• Logging by environment: Development logs everything (Debug, Information), Production logs only important (Warning, Error)
• Security by environment: Development allows CORS from localhost, Production only from trusted domains
• School Management example: Development uses local SQLite, Production uses Azure SQL Server
• Error handling: Development shows stack trace + SQL query, Production shows generic "An error occurred"
• Common mistakes: Committing production credentials, same configuration for all environments, leaving debug mode on production
• Deployment workflow: Code → Development (test) → Staging (validate) → Production (live)

What is an Environment?

An environment tells the application where it is running.

In a school management system:

Environment	Meaning
Development	Developer machine
Staging	Testing server before release
Production	Real server used by school staff, students, and parents

The code may be the same, but settings and behavior can be different.

Why Environments Matter

Development should help developers find problems quickly.

Production should protect users and data.

Example:

Feature	Development	Production
Error details	Full details visible	Generic message
Logging	More detailed	Controlled and useful
Database	Local or test database	Real production database
Caching	Often disabled	Usually enabled
Swagger	Usually enabled	Depends on security decision

Default Environments

ASP.NET Core commonly uses:

Development
Staging
Production

You can technically create custom environment names, but these three are the standard.

Checking the Environment

💻 Try It — Console App

💡 Use app.Environment after builder.Build().⌥ GitHub

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapGet("/debug-info", () => "Development tools enabled");
}

if (app.Environment.IsProduction())
{
    app.UseHsts();
}

app.MapGet("/", () => $"Current environment: {app.Environment.EnvironmentName}");

app.Run();

Useful methods:

app.Environment.IsDevelopment();
app.Environment.IsStaging();
app.Environment.IsProduction();
app.Environment.IsEnvironment("QA");

Environment-Specific Configuration

ASP.NET Core loads configuration based on the environment.

Files:

appsettings.json
appsettings.Development.json
appsettings.Staging.json
appsettings.Production.json

Example base file:

{
  "School": {
    "EnableDemoData": false
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information"
    }
  }
}

Development file:

{
  "School": {
    "EnableDemoData": true
  },
  "Logging": {
    "LogLevel": {
      "Default": "Debug"
    }
  }
}

In Development, demo data can be enabled without changing production behavior.

Setting the Environment

During local development, the environment is often set in launchSettings.json.

{
  "profiles": {
    "School.Api": {
      "commandName": "Project",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

On a server, environment variables are set by hosting configuration.

Common variable:

ASPNETCORE_ENVIRONMENT=Production

Some hosting models also use:

DOTNET_ENVIRONMENT=Production

Development Behavior

Development can include:

• detailed exception pages
• Swagger UI
• seed test data
• relaxed CORS for local frontend testing
• detailed logs

Example:

if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
    app.UseSwagger();
    app.UseSwaggerUI();
}

Production Behavior

Production should include:

• generic error messages
• HTTPS enforcement
• secure headers where applicable
• real database
• controlled logging
• no test endpoints
• no fake data

Example:

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/error");
    app.UseHsts();
}

Staging Behavior

Staging is used to test the release before production.

It should be close to production:

• production-like database structure
• production-like configuration
• production-like logging
• realistic authentication setup

But it should not use real customer or student production data unless carefully protected.

School App Example

Imagine online exam results.

Development:

Use fake student marks.
Show detailed errors.
Allow local frontend URL.

Staging:

Use test copy of exam data.
Run release verification.
Check parent login flow.

Production:

Use real marks.
Hide technical errors.
Log failures securely.

Common Environment Mistakes

Mistake	Result
Running production as Development	Users may see technical error details
Using production database in local dev	Risk of damaging real data
Enabling Swagger publicly without review	Possible API exposure
Forgetting production config	App may run with wrong connection string
Different staging and production setup	Bugs appear only after release

Environment Checklist

Before deployment, check:

• correct environment name
• correct database connection
• correct logging level
• secrets are not in source code
• Swagger policy is intentional
• error handling is production-safe
• CORS policy matches frontend domain

Practice Task

Create environment-specific behavior:

1. Add a route that returns the current environment.
2. Enable a /dev-tools route only in Development.
3. Add appsettings.Development.json.
4. Override a setting from appsettings.json.
5. Print the setting from an endpoint.

Quick Recap

Question	Answer
What is Development?	Local coding environment
What is Staging?	Test environment before production
What is Production?	Live user environment
How do you check environment?	app.Environment.IsDevelopment()
How do config files vary?	appsettings.{Environment}.json

🎯 Interview Favourite

Q: How do environments work in ASP.NET Core?

Good Answer: "ASP.NET Core uses environment names such as Development, Staging, and Production to control behavior and configuration. The current environment is read from variables such as ASPNETCORE_ENVIRONMENT. Code can check it using app.Environment.IsDevelopment(), IsStaging(), or IsProduction(). Environment-specific files like appsettings.Development.json override base settings, allowing different logging levels, connection strings, error handling, and feature flags per environment."

🤖Use AI to Learn Faster

Use ChatGPT, Claude, or Copilot to go deeper on ASP.NET Core Environments. Try these prompts:

• "Explain Development, Staging, and Production with examples."
• "What should be enabled only in Development?"
• "How does appsettings.Development.json override appsettings.json?"
• "What mistakes should I avoid when deploying ASP.NET Core to production?"

💡 Tip: After reading this article, paste your own code into AI and ask "What could go wrong here and why?" — fastest way to find edge cases and deepen understanding.

Next Article

-> Logging with ILogger