app/etc/env.php needs write permission and is rewritten on deployment

[madalinignisca]

Summary

I'm deploying Magento using prebuilt container images.

The one thing that I can't really understand why it is design this way, it is rewriting app/etc/env.php even when it is told to keep-generated, expected by documentation to respect deployments on multiple server/instances.

Also, beside changing other stuff in app/etc/env.php, it also replaces with values from environment variables all calls like getenv('DB_HOST') to returned value.

I find it an anti 12 App Factor pattern writing to app/etc/env.php, principal to what the docs say that Magento is respecting (so it is a proof that 12 App Factor is not respected?)

Examples

If app/etc/env.php has getenv('DB_HOST'), it will be replaced with real_value_from_environment_variable, the file being overwritten.

Proposed solution

If app/etc/env.php contains getenv('XXX') it should not replace it with the calculated value.

app/etc/env.php should never be rewritten and deployment should expose required changes so "ops" can put the configuration and redeploy.

This should be at least optional and usable by some parameters to setup:upgrade to allow protected environments to have app/etc/env.php read-only, and also should be the case for app/etc/config.php, this one expected to be writable only in a development environment and never in production.

Release note

No response

Triage and priority

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant]

Hi @madalinignisca. Thank you for your report.
To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:

• @magento give me 2.4-develop instance - upcoming 2.4.x release
• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this
• To learn more about issue processing workflow, refer to the Code Contributions.

---

Join Magento Community Engineering Slack and ask your questions in #github channel.
⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
🕙 You can find the schedule on the Magento Community Calendar page.
📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

[hostep]

Just linking some older discussions to this issue:

• Read-only app/etc/ #26292
• Separate cache_types from app/etc/config.php #32605

[madalinignisca]

@hostep I read the last few days the discussions. I should have gotten involved in them directly.

I think we should stick to a more concise feature request as when Magento is in PRODUCTION mode, it must never alter any file, but only do DB, Elastic, RabbitMQ structure update and migration of needed data.

This will just make Magento "modern cloud" compatible.

[engcom-November]

Hello @madalinignisca,

As the same issue is already been confirmed here #26292, we believe we can close this issue. If you need further assistance on this feel free to raise a fresh ticket or reopen this ticket.

Thank you.