The dev image sets the sentinel APP_ENV=xxxxxxx in the Dockerfile, which /entrypoint unsets on container start so .env wins. That works for the supervisord processes — but docker compose exec bypasses the entrypoint, so the sentinel is still set there.
Since real env vars override .env in Symfony, every exec'd console command runs in an environment literally named xxxxxxx:
$ swx cache:clear
[OK] Cache for the "xxxxxxx" environment (debug=true) was successfully cleared.
$ docker compose exec web sh -c 'echo $APP_ENV'
xxxxxxx
This is more than cosmetic: shopware-cli project console / swx commands use var/cache/xxxxxxx_ while the web processes use var/cache/dev_ — e.g. cache:clear clears the wrong cache.
Image: ghcr.io/shopware/docker-dev:php8.5-node24-caddy (current build)
Workaround: set APP_ENV: dev explicitly in the compose environment: block.
The dev image sets the sentinel
APP_ENV=xxxxxxxin the Dockerfile, which/entrypointunsets on container start so.envwins. That works for the supervisord processes — butdocker compose execbypasses the entrypoint, so the sentinel is still set there.Since real env vars override
.envin Symfony, every exec'd console command runs in an environment literally namedxxxxxxx:This is more than cosmetic:
shopware-cli project console/swxcommands usevar/cache/xxxxxxx_while the web processes usevar/cache/dev_— e.g.cache:clearclears the wrong cache.Image:
ghcr.io/shopware/docker-dev:php8.5-node24-caddy(current build)Workaround: set
APP_ENV: devexplicitly in the composeenvironment:block.