[Suggestion] - Add option to prevent confluence.cfg.xml regeneration on pod restarts

[ram-devsecops]

Suggestion

Problem Description:
When deploying Confluence using the Helm chart, the confluence.cfg.xml file is regenerated every time the pod restarts, causing Confluence to return to the setup page. This happens even with properly configured persistent volumes for both local-home and shared-home. This makes running Confluence in Kubernetes environments unreliable, as any pod restart (scaling, node failures, or updates) forces users to go through setup again or requires complex workarounds.

Use Case
Our organization is currently migrating our Confluence instance to Amazon EKS using Helm charts. During this migration process, we've encountered persistent issues with configuration stability. After completing the initial Confluence setup, any pod restart (whether due to deployment updates, testing, or simulated node failures) causes Confluence to reset to the setup page. This significantly impedes our migration efforts as:

It blocks our ability to properly test Kubernetes features like auto-scaling and self-healing
It undermines confidence in the reliability of the deployment for production use
It introduces unnecessary complexity to our migration process through workarounds
It prevents us from establishing proper CI/CD pipelines for our Atlassian tools

Feature Request
Add a Helm chart value that prevents confluence.cfg.xml regeneration on pod restarts, such as:

confluence:
  persistConfiguration: true

Suggested implementation approaches:

Add parameters to control the Docker entrypoint behavior
Add options to mount existing configuration as read-only files
Provide an officially supported method to pass a complete configuration file via ConfigMap

Expected Behavior
When persistConfiguration is set to true, Confluence should:

Only generate configuration files on first startup (if they don't exist)
Respect and preserve existing configuration files on subsequent restarts
Allow configuration updates through the Confluence UI to be persisted

This would bring Confluence Helm charts in line with standard Kubernetes patterns for stateful applications where configuration persistence is expected and would significantly simplify the migration process to Kubernetes platforms like EKS.

Additional Question
If there is currently an officially recommended way to address this issue with the current Helm chart, we would appreciate guidance on the best practice approach. Our team is looking for the most reliable solution that doesn't compromise upgrade paths or require extensive customization.

Product

Confluence

Code of Conduct

• I agree to follow this project's Code of Conduct

[bianchi2]

@ram-devsecops confuence.cfg.xml should not be regenerated if the file exists, unless you set confluence.forceConfigUpdate to true or pass ATL_FORCE_CFG_UPDATE to true in additionalEnvironmentVariables.

After completing the initial Confluence setup, any pod restart (whether due to deployment updates, testing, or simulated node failures) causes Confluence to reset to the setup page.

This definitely looks like misconfiguration on your side. A properly setup clustered confluence can be scaled, you can restart pods etc.

This is the entrypoint in the container image. So, if you have confluence.cfg.xml in your local-home, it won't be overwritten.

For clustered Confluence, you may not even persist local-home, confluence.cfg.xml will be regenerated on each restart, but it's confluence.cfg.xml in shared-home that matters.