JHipster Docker Compose relies on mutable latest tags for services

When generating a repeatable development environment, JHipster creates a docker‑compose.yml that uses the latest tag for the application, database, and monitoring containers.

This configuration depends on Docker Hub's mutable latest tag, which can change between pulls and lead to inconsistent images across machines or CI runs. The goal is to guarantee that the same binary images are used each time the environment starts, but the generated file does not include explicit version pins or digest references, and the standard documentation does not describe a preferred way to override these tags.

What versioning strategy should be adopted for the generated compose file? Should JHipster provide a mechanism to pin image versions without complicating upgrades? Is there a recommended practice for teams to enforce reproducible images while keeping the getting‑started guide simple?