Format an App Config JSON File

Application configuration files that live in source control are a cornerstone of modern twelve-factor app design. They let you separate configuration from code, document expected settings with examples, and review configuration changes in pull requests alongside the code changes they support. A malformed JSON config file discovered at runtime in production causes an immediate outage, making pre-deployment validation essential. This example shows a realistic app config with four common sections: the app block with basic metadata and the current environment, a features block with feature flags for toggling functionality without code deploys, a database block with connection details, and a services block declaring which third-party providers are active. Feature flags deserve special attention. The pattern of storing boolean values like darkMode: true and betaDashboard: false in a config file lets you turn features on or off with a config change and redeploy, without modifying source code. More sophisticated setups use a feature flag service (LaunchDarkly, Flagsmith, Unleash) instead of a static file, but the JSON structure concept is identical. Real-world scenarios: a staging deployment crashes on startup because a developer added a new required config key in code but forgot to add it to the config file — validating the config file against a schema before deployment catches this. A feature gets accidentally enabled in production because a merge from the feature branch brought in a config file change that overrode the production setting. Tips and pitfalls: never store passwords, API keys, or other secrets in JSON config files that are committed to source control. Secrets belong in environment variables or a secrets manager like AWS Secrets Manager, HashiCorp Vault, or a CI/CD platform's secret store. The config file should contain only non-sensitive settings, with the sensitive values referenced by name (e.g., "apiKeyEnvVar": "STRIPE_SECRET_KEY") so developers know which environment variables they need to set. To use this example: format your application's config file here to tidy indentation, then validate it to ensure there are no syntax errors that would cause a parse failure at startup. Consider adding a startup validation step that throws an error listing all missing required keys before the application accepts any traffic.

{
  "app": { "name": "MyApp", "version": "2.1.0", "environment": "production" },
  "features": {
    "darkMode": true,
    "betaDashboard": false,
    "newOnboarding": true
  },
  "database": {
    "host": "db.example.com",
    "port": 5432,
    "name": "myapp_prod"
  },
  "services": {
    "emailProvider": "sendgrid",
    "analyticsEnabled": true
  }
}