Namespace deletion permissions
To delete a Namespace in Temporal Cloud, a user must have Namespace Admin permission for that Namespace.
Temporal · Concepts · all subjects
namespaces & retention
25 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Cloud Namespace Name format and rules
A Cloud Namespace Name is a customer-supplied name that must contain at least 2 characters and no more than 39 characters. It must begin with a letter, end with a letter or number, and contain only letters, numbers, and the hyphen (-) character. All letters must be lowercase. Each Namespace Name is unique within the scope of a customer's account and cannot be changed after provisioning.
Cloud Namespace ID composition
A Cloud Namespace ID is formed by concatenating a Namespace Name, a period (.), and an Account ID. For example, accounting-production.123de is a complete Namespace ID. The Namespace Name alone is insufficient; all Temporal Cloud operations require the full Namespace ID.
Temporal Cloud Account ID characteristics
A Temporal Cloud Account ID is a unique customer identifier assigned by Temporal Technologies. Each ID is a short string of numbers and letters, at least five characters long, such as f45a2. It is part of every Namespace ID in an account and is retained while using Temporal Cloud.
Namespace endpoint type and behavior
A Namespace endpoint has the format <namespace>.<account>.tmprl.cloud:7233 and is recommended. This endpoint is unique to each Namespace and always connects to the Namespace regardless of which region(s) it uses. A Temporal Client using a Namespace endpoint does not need to be aware of the Namespace's region. For Namespaces with High Availability, the Namespace endpoint automatically directs traffic to the active region during failover.
Regional endpoint type and behavior
A regional endpoint has the format <region>.<cloud_provider>.api.temporal.io:7233. Temporal Cloud has one regional endpoint for each cloud region, and the same endpoint can access any Namespace active in that region or with a replica in that region. A Temporal Client can use a regional endpoint to ensure connection within that region. When using mTLS with a regional endpoint, the client must set the server_name property to the Namespace endpoint value to provide the correct SNI header during the TLS handshake.
Retention period for Namespace Event History
When creating a Namespace, a retention period must be specified from 1 to 90 days for the Event History of closed Workflow Executions. A development Namespace typically has a short retention period while a production Namespace typically has a longer retention period. The retention period can be changed in the Temporal Cloud UI under the namespace's Settings tab or by using the Temporal CLI.
Namespace creation permissions
To create a Namespace in Temporal Cloud, a user must have Developer, Account Owner, or Global Admin account-level Role. The user who creates a Namespace is automatically granted Namespace Admin permission for that Namespace.
Default Namespace quota and expansion
By default, each Temporal Cloud account starts with 10 Namespaces. This limit increases automatically when existing Namespaces have scheduled or running Workflow Executions. For large-scale needs, a support ticket can be opened.
Information required to create a Namespace
To create a Namespace in Temporal Cloud, the following information must be gathered: Namespace Name, region, and Cloud Provider; Retention Period for Event History of closed Workflow Executions; CA certificate for the Namespace if using mTLS authentication; Codec Server endpoint to show decoded payloads in Event History for Workflow Executions; and Permissions for each user.
Namespace deletion behavior and permanence
After deleting a Temporal Cloud Namespace, the Temporal Service immediately removes the Namespace's Workflow Executions and Task Queues. Closed Workflow Histories remain in Temporal storage until the user-defined retention period expires, reflecting the policy in effect when the Workflow Execution was closed. Namespace removal is permanent.
Namespace deletion protection feature
Temporal Cloud provides a deletion protection feature to prevent accidental Namespace deletion. When enabled on a production Namespace, it ensures critical data will not be deleted unintentionally. Deletion Protection can be enabled in the Namespace Edit page under Security settings or via tcld namespace lifecycle set command with the --enable-delete-protection flag.
Namespace tags structure and limits
Each Namespace can have a maximum of 10 tags. Each tag key must be unique per Namespace. Keys and values must be 1-63 characters in length. Allowed characters are lowercase letters (a-z), numbers (0-9), periods (.), underscores (_), hyphens (-), and at signs (@). Tags are not a secure storage mechanism and should not store PII or PHI. Tags will not change the behavior of the tagged resource. There is a soft limit of 1000 unique tag keys per account.
Namespace tag permissions
Only Account Admins and Account Owners can create and edit Namespace tags. All users with access to a Namespace can view its tags.
Temporal Web UI access endpoint format
To access the Temporal Web UI, use the HTTPS endpoint in the form https://cloud.temporal.io/namespaces/<namespace>.<account>. For example: https://cloud.temporal.io/namespaces/accounting-production.f45a2.
Stable IPs for Namespace endpoint DNS resolution
Temporal Cloud guarantees the DNS resolution behavior of the Namespace Endpoint when Stable IPs are enabled. The Namespace Endpoint resolves to one of the Stable IPs for the Namespace's active region. IP addresses without this feature are subject to change without notice.
High Availability with Private Connectivity DNS resolution
For High Availability features with Private Connectivity, the Namespace Endpoint resolves to a regional intermediary in the format <provider>-<region>.region.tmprl.cloud. This can be overridden in a Route 53 private hosted zone or GCP private DNS zone to point at your VPC Endpoint.
DNS dependency warning for Temporal Cloud endpoints
Do not take dependencies on Temporal Cloud endpoint DNS resolution or configure Workers, Temporal Clients, or firewalls against specific IPs observed for an endpoint at any point in time, as IP addresses are subject to change without notice.
Namespaces for environment isolation
Temporal Namespaces can be used to isolate workflows for different environments or teams (development, staging, production). Each Namespace is logically segregated and cannot interact with others by default, providing a security boundary. Production Namespaces should use stricter network controls accessible only from the prod network, with separate credentials from non-prod Namespaces. Workflow data is only visible to users with access to that Namespace, enforcing data-visibility boundaries.
Namespace Retention Period setting
Temporal Cloud Namespace has a Retention Period setting for workflow histories ranging from 1 to 90 days. Set an appropriate retention period to balance operational needs with security; shorter retention means completed workflow data (history, payloads) is purged sooner, reducing sensitive data stored in the cloud. For retention periods over 90 days, data can be exported to your own GCS or S3 buckets.
Namespace version concept in Multi-Cluster Replication
A version is a concept in Multi-Cluster Replication that describes the chronological order of events per Namespace. With asynchronous replication across clusters, data is not strongly consistent. To guarantee eventual consistency and handle conflicts during failover, a version is attached to Namespaces. All Workflow Execution History entries generated in a Namespace come with the version attached to that Namespace.
Namespace version values representation
Namespace version values represent the chronological order of events per Namespace. All participating Clusters are pre-configured with a unique initial version and a shared version increment, where initial version < shared version increment. Namespace versions increment according to a failover rule: for all versions which follow 'version % (shared version increment) == (active cluster's initial version)', find the smallest version which has 'version >= old version in namespace'.
Conflict resolution using version comparison
When there is a data conflict, a comparison is made and Workflow Execution History entries with the highest version are considered the source of truth. When a cluster attempts to mutate a Workflow Execution History, the version is checked. A cluster can mutate only if: (1) the version in the Namespace belongs to this cluster, meaning (version in namespace) % (shared version increment) == (this cluster's initial version), and (2) the version of the Workflow Execution History's last entry is equal to or less than the version in the Namespace, meaning (last event's version) <= (version in namespace).
Namespace version increment example with three clusters
Example of namespace version behavior: With Cluster A (initial version 1), Cluster B (initial version 2), Cluster C (initial version 3), and shared version increment 10: When a namespace is registered with Cluster A as active, its version is 1. When failover occurs to Cluster B, the version becomes 2. When failover then occurs to Cluster A again, the version becomes 11 (following the rule that the next valid version after 2 where version % 10 == 1 is 11). This ensures versions uniquely identify which cluster was the active one.
Workflow ID Reuse Policy and Retention Period
The first three values of the Workflow ID Reuse Policy (Allow Duplicate, Allow Duplicate Failed Only, and Reject Duplicate) apply to Closed Workflow Executions that are retained within the Namespace. The Temporal Service can only check the Workflow ID of the spawning Workflow Execution against Closed Workflow Executions retained within the Retention Period. If you need to start a Workflow only if it hasn't started yet, ensure your Retention Period is long enough to check against. Consider using Workflow message passing instead if this becomes unwieldy.