Persistency of Temporal Namespaces Retention

Community Support Server Deployment
1

I’m deploying Temporal using the official Helm chart (v0.29.0) and want to ensure that my namespaces are always created or updated with the correct retention period (e.g., 182d), and that this is fully aligned with my deployment process.

Problem:

  • The Helm chart has a server.config.namespaces (or server.namespaces) block, but changing this value does not actually create or update namespaces at deploy time.
  • If I manually run tctl namespace register or tctl namespace update before or after deployment, a future redeploy reverts the retention to the default (e.g., 3d).
  • I need a solution where the deployment itself always sets the correct retention, and never risks reverting it or causing data loss.

What I’ve tried:

  • Setting the desired retention in values.yaml under server.config.namespaces (or server.namespaces).
  • Forcing pod restarts and redeploys.
  • Manually running tctl to update retention, but this is not safe as the deployment overwrites it later.

The Solution I’m Trying To Achieve:

  • Namespace creation and retention must be managed by the deployment, not by a manual or out-of-band script.
  • The solution must be idempotent and safe for redeploys (never reverts retention to a lower value).
  • No risk of data loss due to retention being reset on redeploy.

My Question:

Is there a way to have the Temporal Helm chart always create/update namespaces with the correct retention, fully aligned with the values in my deployment?
If not, what is the best practice for automating namespace creation/updating as part of a Helm-based deployment, so that retention is never accidentally reverted?

1 Like
2

See server job template section here

Can then use config to define default retention period you want to set if not explicitly defined.

3

Hi Tihomir, thanks for your assistance.
The issue with this solution would be that in that way there would be data loss at each upgrade.
I’d have retention of lets say 182 days, upgrade - which resets retention to 3 days, then the server job updates the retention again to 182 days, so the data that would be kept would only be the last 3 days as the upgrade would delete the data before re-setting 182 days as retention.

4

Not sure I fully understand, do you recreate your namespaces on server version upgrades?

5

No, but for example an upgrade that has reset the retention of my namespace was including the setting of

server.config.persistence.default.sql.driver

from ‘postgres’ to ‘postgres12’.

When I ran helm upgrade with this change on my lower environments, it has reset the namespaces retention. I am now looking for a solution that won’t reset the retention during an upgrade, for higher environments, and in general.