Magento 2.2 Shared Configuration Boundary: Promoting Search, Cache, and Queue Backends into config.php
0 reputation · 21 Jan 2023, 18:31 UTC
0 reputation · 21 Jan 2023, 18:31 UTC
Magento 2.2 introduced configuration management that splits shared settings into app/etc/config.php and environment-specific values into app/etc/env.php. In production mode, config.php is authoritative. The platform does not enforce a boundary between shared and environment-specific settings, so backends for search, full-page cache, and message queues configured in Admin before a dump can be promoted into config.php and locked for every environment that shares that file.
A deployment can appear successful in logs while the application fails at runtime because config.php references a backend that exists only in staging. The resulting error surfaces in var/log or var/report rather than in the deploy output. Because no supported command dumps everything except chosen scopes, teams must decide which entries are safe to promote and which must remain in env.php.
When a shared config.php is promoted between environments, how should teams classify catalog/search, system/full_page_cache, and queue/AMQP settings to avoid locking staging-only backends into production? What verification steps confirm that the configuration import has not overwritten environment-specific values in env.php? Is there a documented compatibility boundary for which backends are safe to share across environments in a given Magento 2.2 branch?
33275 reputation · 21 Jan 2023, 21:47 UTC
Keep all connection‑specific values (host, port, credentials, index names, virtual hosts, etc.) for catalog/search, system/full_page_cache, and queue/AMQP in app/etc/env.php. Only promote generic toggles that are identical across environments—such as the search engine selection, cache type flag, or queue driver—to app/etc/config.php. This prevents staging‑only backends from being locked into production.
bin/magento app:config:dump) places all non‑sensitive configuration in config.php by default.env.php unless the --lock-env flag forces them into config.php.catalog/search/, system/full_page_cache/, and queue/ from the shared dump unless overridden.catalog/search/server_host, catalog/search/server_port, catalog/search/index_prefixsystem/full_page_cache/backend/redis/server, system/full_page_cache/backend/redis/port, system/full_page_cache/backend/redis/password (or analogous Varnish settings)queue/amqp/* entries such as host, port, username, password, virtualhostbin/magento app:config:dumpapp/etc/config.php and verify that none of the keys listed above appear. If any are present, remove them manually or edit the dump command to exclude them.app/etc/env.php retains those keys with the correct values for each environment.bin/magento cache:clean config
bin/magento cache:flushsetup:upgrade or setup:di:compile if needed, then verify the storefront works.bin/magento config:show <path> for each connection‑related path; the output should reflect the values from env.php (you can confirm by temporarily changing a value in env.php and seeing the change in the output).var/log and var/report after a page load; there should be no exceptions indicating missing search, cache, or queue services.config.php against a known‑good baseline to ensure no unintended environment‑specific entries were added.Magento 2.2.x documentation states that the following configuration paths are not safe to share across environments and must remain in env.php:
catalog/search/* (host, port, index, authentication)system/full_page_cache/* (backend server, port, password, timeout)queue/amqp/* (RabbitMQ host, port, username, password, virtual heart)Only the generic switches that do not contain connection details—e.g., catalog/search/engine, system/full_page_cache/caching_application, queue/consumers/* driver selection—can be safely locked into config.php.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.