Skip to main content

How to set up Archival

Archival consists of the following elements:

  • Configuration: Archival is controlled by the server configuration (i.e. the config/development.yaml file).
  • Provider: Location where the data should be archived. Supported providers are S3, GCloud, and the local file system.
  • URI: Specifies which provider should be used. The system uses the URI schema and path to make the determination.

Take the following steps to set up Archival:

  1. Set up the provider of your choice.
  2. Configure Archival.
  3. Create a Namespace that uses a valid URI and has Archival enabled.


Temporal directly supports several providers:

  • Local file system: The filestore archiver is used to archive data in the file system of whatever host the Temporal server is running on. This provider is used mainly for local installations and testing and should not be relied on for production environments.
  • Google Cloud: The gcloud archiver is used to connect and archive data with Google Cloud.
  • S3: The s3store archiver is used to connect and archive data with S3.
  • Custom: If you want to use a provider that is not currently supported, you can create your own archiver to support it.

Make sure that you save the provider's storage location URI in a place where you can reference it later, because it is passed as a parameter when you create a Namespace.


Archival configuration is defined in the config/development.yaml file. Let's look at an example configuration:

# Cluster level Archival config
# Event History configuration
# Archival is enabled at the cluster level
state: "enabled"
enableRead: true
# Namespaces can use either the local filestore provider or the Google Cloud provider
fileMode: "0666"
dirMode: "0766"
credentialsPath: "/tmp/gcloud/keyfile.json"

# Default values for a Namespace if none are provided at creation
# Archival defaults
# Event History defaults
state: "enabled"
# New Namespaces will default to the local provider
URI: "file:///tmp/temporal_archival/development"

You can disable Archival by setting archival.history.state and namespaceDefaults.archival.history.state to "disabled".


state: "disabled"

state: "disabled"

The following table showcases acceptable values for each configuration and what purpose they serve.

ConfigAcceptable valuesDescription
archival.history.stateenabled, disabledMust be enabled to use the Archival feature with any Namespace in the cluster.
archival.history.enableReadtrue, falseMust be true to read from the archived Event History.
archival.history.providerSub provider configs are filestore, gstorage, s3, or your_custom_provider.Default config specifies filestore.
archival.history.provider.filestore.fileModeFile permission stringFile permissions of the archived files. We recommend using the default value of "0666" to avoid read/write issues.
archival.history.provider.filestore.dirModeFile permission stringDirectory permissions of the archive directory. We recommend using the default value of "0766" to avoid read/write issues.
namespaceDefaults.archival.history.stateenabled, disabledDefault state of the Archival feature whenever a new Namespace is created without specifying the Archival state.
namespaceDefaults.archival.history.URIValid URIMust be a URI of the file store location and match a schema that correlates to a provider.

Namespace creation

Although Archival is configured at the cluster level, it operates independently within each Namespace. If an Archival URI is not specified when a Namespace is created, the Namespace uses the value of defaultNamespace.archival.history.URI from the config/development.yaml file. The Archival URI cannot be changed after the Namespace is created. Each Namespace supports only a single Archival URI, but each Namespace can use a different URI. A Namespace can safely switch Archival between enabled and disabled states as long as Archival is enabled at the cluster level.

Archival is supported in Global Namespaces (Namespaces that span multiple clusters). When Archival is running in a Global Namespace, it first runs on the active cluster; later it runs on the standby cluster. Before archiving, a history check is done to see what has been previously archived.

Test setup

To test Archival locally, start by running a Temporal server:

./temporal-server start

Then register a new Namespace with Archival enabled.

./tctl --ns samples-namespace namespace register --gd false --history_archival_state enabled --retention 3

If the retention period isn't set, it defaults to 2 days. The minimum retention period is 1 day. The maximum retention period is 30 days.

Setting the retention period to 0 results in the error A valid retention period is not set on request.

Next, run a sample Workflow such as the helloworld temporal sample.

When execution is finished, Archival occurs.

Retrieve archives

You can retrieve archived Event Histories by copying the workflowId and runId of the completed Workflow from the log output and running the following command:

./temporal --ns samples-namespace wf show --wid <workflowId> --rid <runId>