Feature Request: Export user-secrets keys as appsettings.template.json for safer environment config sharing

[Hexatox]

Summary

I’d like to propose a new feature for the .NET CLI to help developers sync and document required user secrets without exposing sensitive values. Specifically, the feature would allow exporting only the keys of secrets stored via dotnet user-secrets to a file like appsettings.template.json.

---

Problem

In collaborative or distributed environments, it's common to use dotnet user-secrets for storing sensitive config values locally. However:

• There is no native way to export just the keys of secrets to inform other team members or CI/CD pipelines about what environment variables or secrets they need to provide.
• Developers often forget what keys they had configured, especially when returning to the project after some time.
• Manual synchronization between user-secrets and appsettings.json (or a .env-style placeholder file) becomes error-prone.

---

Proposed Solution

Add a new CLI command (or a flag) to export just the secret keys from the current project’s user-secrets:

dotnet user-secrets export --keys-only > appsettings.template.json

Or as a separate command:

dotnet user-secrets sync-template

This would generate an output like:

{
  "ConnectionStrings": {
    "Default": "<TO_BE_PROVIDED>"
  },
  "Jwt": {
    "Issuer": "<TO_BE_PROVIDED>",
    "Key": "<TO_BE_PROVIDED>"
  }
}

🔒 Keeps secrets safe (no values exposed)

📦 Provides a standardized, sharable template

👥 Improves team collaboration and onboarding

🚀 Helps CI/CD environments understand required config keys

✅ Mirrors common .env.example practice found in Node.js and other ecosystems

Alternatives Considered
Manually documenting keys in README

Using a fake appsettings.Development.json with dummy values (risky if accidentally committed)

Writing custom scripts to parse secrets.json

[baronfel]

Sending this to the aspnetcore repo since the ASP.NET team owns the user-secrets tool. In addition, if a template mechanism were provided for appsettings, it's likely that the default HostApplicationBuilder and WebHostApplicationBuilders would need to be updated to take advantage of it.