Evergreen Tracks
Every dotCMS Cloud environment updates automatically along one of three release tracks. Run your dev and QA environments ahead of production, and every release gets tested against your implementation before production sees it. No code branches, no backports, no upgrade projects.
What Evergreen Tracks Are#
An Evergreen Track controls how fresh a release each of your environments receives. Every track installs the same released artifacts. The only difference is when. A release lands on the Latest track first, then advances to Standard and Trailing as it ages.
Tracks describe version age, not a custom schedule. We decide when each track advances, guided by the dotCMS release and support lifecycle and by how each release performs under real usage. We're always monitoring releases and listening to feedback.
The Three Tracks#
| Track | What it runs | Recommended For |
|---|---|---|
| Latest | The newest release, as soon as it ships | Dev and QA environments, and teams with solid CI/CD that want fixes and features the day they ship |
| Standard | The newest release that is at least 14 days old | Production. This is the default. |
| Trailing | The newest release that is at least 28 days old | Production for teams whose change control needs a longer validation window |
Timings are for dotCMS Cloud and may change.
dotCMS Cloud environments start on Standard.
How Updates Work#
- Automatic and age gated. Latest environments update as releases ship. Standard and Trailing environments update every other week in your maintenance window, to the newest release that has aged into their track.
- Bad releases are skipped. If we find a serious problem in a release, we mark it Not recommended on the release pages and on Docker Hub, and Standard and Trailing never advance to it. They wait for the fixed release instead.
- Zero downtime. Updates apply as in-place rolling updates. Your environment keeps serving traffic the whole time.
- See what changed. Every release and its changes are published in the changelogs.
Setting Up Your Environments#
Run at least one environment ahead of production. That environment is your early warning: every release reaches it first, so anything that breaks your implementation breaks there, weeks before it can reach production.
Our recommendation: Dev and QA on Latest, production on Standard.
| Environment | Track |
|---|---|
| Dev | Latest |
| QA / Staging | Latest |
| Production | Standard |
This is the sweet spot. You get security fixes, bug fixes and new features quickly, and every release soaks in your non-production environments for at least two weeks before production sees it. If something breaks in Dev or QA, you have until that release reaches Standard to fix it.
Need a four-week window for formal change control? Keep Dev and QA on Latest and put production on Trailing. We recommend that you don't put every environment on the same track. Testing only helps when it happens ahead of production. Trailing isn't safer on its own; it's later.
Only have one environment? Add a dev environment to your dotCMS Cloud subscription, or run your own on the dotcms/dotcms:latest image. If you run your own, remember latest is a moving tag: set your image pull policy to Always (or pull before each test run) so a cached image doesn't leave you testing an old release.
What to Test#
Your Latest environment only protects production if you test there. Automate as much as you can and run it every time a release lands.
- Plugins and OSGi bundles. Confirm every bundle starts and stays active, and that your plugin features still work end to end. Plugins are the most common way an update breaks an implementation.
- Your critical pages and APIs. List the pages, REST and GraphQL calls, and content flows your business depends on, and turn that list into automated tests. AI coding tools make these quick to write, and our Professional Services team can help you build them.
- Your implementation specifics. Custom templates, Velocity, workflows, integrations, and any other extension you've built on top of dotCMS.
- SDK warnings. If you use a dotCMS SDK, watch your dev console for minimum-version warnings and upgrade the SDK before that release reaches production.
- The changelogs. Skim each release's changelog for changes to features you use, and test those first.
If You Find a Bug#
Open a ticket with dotCMS Support as soon as your tests catch something. The earlier we hear about it, the earlier we can help, whether that's guidance on following best practices in your implementation or a fix on our side.
Security issues are handled case by case. Critical ones may get special attention or remediation outside normal Evergreen Tracks timing. Contact Support with any specific questions or concerns, or report a vulnerability through our responsible disclosure policy.
Changing Tracks#
Reach out to dotCMS Support and we'll move any of your environments to the track you want, or confirm which track an environment is on today. Self-service track selection is on our roadmap.
- Moving to a faster track takes effect as soon as our support team makes the change.
- Moving to a slower track never rolls a running version backward. Your environment stays put until its current version ages into the new track, and updates resume from there.