Should I push appsettings.json file on GitHub in .NET application?

Usually: no, 

not the real appsettings.json with secrets.

In a .NET app, appsettings.json often contains things like:

• Database connection strings
• API keys
• JWT secrets
• SMTP credentials
• Azure/AWS keys
• Third-party service credentials

Those should never go to a public GitHub repo.

A good practice is:

What to commit

Commit:

• appsettings.json → only if it contains non-sensitive defaults
• appsettings.Development.json → generally avoid if it has local secrets
• appsettings.Example.json or appsettings.template.json → recommended

Example safe template:

{
  "ConnectionStrings": {
    "DefaultConnection": "YOUR_CONNECTION_STRING"
  },
  "Jwt": {
    "Key": "YOUR_SECRET_KEY"
  }
}

What to keep out of GitHub

Do NOT commit:

• Production secrets
• API keys
• Passwords
• Real connection strings
• OAuth secrets
• Certificates

Add sensitive files to .gitignore if needed:

appsettings.Development.json
appsettings.Local.json

Recommended approach in .NET

1. Use appsettings.json for defaults only

{
  "Logging": {
    "LogLevel": {
      "Default": "Information"
    }
  }
}

2. Store secrets using User Secrets (development)

Use the built-in .NET Secret Manager:

dotnet user-secrets init

Set secrets:

dotnet user-secrets set "ConnectionStrings:DefaultConnection" "your-secret"

Microsoft docs:

ASP.NET Core Secret Manager documentation

3. Use environment variables in production

For Docker, Azure, AWS, Render, Railway, etc.:

ConnectionStrings__DefaultConnection=...
Jwt__Key=...

Best structure

appsettings.json                 ✅ safe defaults
appsettings.Development.json     ❌ local secrets
appsettings.Production.json      ❌ production secrets
appsettings.template.json        ✅ shareable template

If you already pushed secrets to GitHub

Immediately:

• Rotate/revoke the secrets
• Remove them from git history
• Force push cleaned history

Useful tool:

BFG Repo-Cleaner

For professional .NET projects, the common pattern is:

• Commit configuration structure
• Never commit actual secrets
• Use Secret Manager locally
• Use environment variables or vaults in production