Upgrade workflow: follow repo tags or bump services individually to stay current?

[pt-sits]

Hi all — I’m starting a new shop on docker-magento and want to stay up to date across Magento and services (DB, OpenSearch, RabbitMQ, Redis, etc.). I’ve seen related threads on version moves and compatibility (e.g. 2.4.2 → 2.4.7, RDBMS/version support, and 2.4.7 → 2.4.7-p2), but I’m unsure what the intended path is here.

Is the project intended to be used by tracking the repo’s tags (moving the whole stack together as those tags are published), or do people commonly bump individual services via compose overrides to get newer DB/OpenSearch/RabbitMQ sooner?

It'd be great to get some insight into your guys and gals' strategies here:

Your go-to strategy (upgrade in lockstep with this repo or bump individual components?) and why?
Your Rules of thumb for when to bump the repo tag vs a single service.
Known gotchas (e.g., DB/image migrations or MariaDB compatibility messages).

Context: fresh project; goal is to stay current without fighting the stack.

If there’s an official recommendation from maintainers on upgrade cadence, I’d love to follow that!!

Many thanks in advance!!! P

[dosubot[bot]]

Hi @pt-sits! I'm Dosu and I’m helping the docker-magento team.

Most users and maintainers upgrade docker-magento by tracking repo tags for major Magento releases, since these tags provide a tested baseline for service versions and compatibility. However, it's common to bump individual services in compose.yaml to address specific needs or compatibility issues—especially for PHP, MariaDB, Redis, Elasticsearch/OpenSearch, and RabbitMQ—when Magento requirements change or upstream images get security updates. This hybrid approach is widely used because repo tags sometimes lag behind the latest service versions or don't match all project needs discussion issue.

Rules of thumb: upgrade the whole stack (by moving to a new repo tag) when you want a tested, stable environment or when Magento itself is upgraded; bump individual services when you need a newer version for a bugfix, security patch, or to meet Magento's system requirements. Always check the Adobe Commerce system requirements and use the bin/check-dependencies script to verify compatibility discussion issue.

Known gotchas: MariaDB must be 10.2–10.6 for Magento 2.4.7/2.4.8—using 11.x will break setup and require you to recreate the DB volume issue. Elasticsearch 8.x is not supported by Magento 2.4.5 and below; use 7.x for those versions issue. Xdebug 3.3.x causes 502 errors with PHP 8.3 and Blackfire; downgrading Xdebug to 3.2.2 works for PHP 8.1/8.2, but not for 8.3. There's now a bin/blackfire script to toggle Blackfire for PHP 8.3 issue.

Best practices: always back up your DB before upgrading, test changes in staging, and review Magento release notes for breaking changes. Building images locally from the /images directory can help keep your team on exact versions issue.

There’s no strict official cadence—maintainers support only the latest and one-version-behind Magento releases, and recommend service-level updates over package-level ones. For a fresh project, following repo tags for major upgrades and selectively bumping services for minor updates is the safest way to stay current without fighting the stack.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}