Which configuration source should own secrets in CakePHP: env() placeholders in app.php or a deployed app_local.php?

We run a CakePHP application where everything works locally but behaves differently in production, and the root cause keeps coming back to configuration layering. CakePHP loads config/app.php and then merges config/app_local.php on top, but the skeleton gitignores app_local.php, so any value defined only there silently vanishes on a fresh production deploy. Values can also come from environment variables via env() calls inside app.php (for example DATABASE_URL or Security.salt), which means the effective configuration depends on the process environment rather than committed files.

The unresolved decision for our team is where environment-specific secrets and overrides should canonically live. Committing app.php with env() placeholders centralizes defaults but pushes secret management entirely into the deployment platform, while deploying a per-environment app_local.php keeps overrides explicit but outside version control and harder to audit or rotate. CakePHP supports both and does not mandate one. We also know stale compiled caches under tmp/cache can mask config changes, which complicates comparing the two approaches.

Assume a current CakePHP 4.x/5.x application deployed behind a standard PHP-FPM setup.

Which approach do teams treat as the single source of truth for production secrets, and why? Does mixing both (defaults in app.php, overrides in app_local.php) create precedence pitfalls worth avoiding? What is the safest way to verify which source actually supplied a given value in the running production process?