Temporal archival to S3 or Google Cloud Storage

When Temporal archival to S3 or Google Cloud Storage keeps histories past retention

Temporal archival lets you keep closed workflow histories after the namespace retention period ends, by copying them to Amazon S3 or Google Cloud Storage before Temporal deletes them. Teams need this when audit, incident investigation or dispute handling may require a workflow's full event history long after it completed. Without archival, Temporal deletes the history when the namespace retention period ends, so the decision has to be made before that window closes, not after a dispute arrives.

Archival is configured at two levels. The service must be set up to archive and to write to a supported object storage provider, and each namespace must then be set up to use archival with its own destination. Confirm in the current configuration reference which settings belong to the service and which to the namespace, and whether both must be in place before any history is archived. The topic notes a fixed archival URI and a Docker restriction. Confirm both against the current documentation before you design bucket layouts, naming or the container image your workers and server will run from.

Temporal documents archival as experimental. That label changes the decision. Before you enable it for production namespaces, ask what happens when an archive write fails, whether a history can be deleted after a failed archive, how you detect failures, and who is responsible for monitoring them. Also confirm that an archived history can be read back and is complete for the investigations you expect to run. Record the maturity statement for the exact server version you plan to run. The current release line includes v1.32.1, published on October 8, 2026, and patch releases v1.31.4 and v1.30.8, published on October 12, 2026, so check which line your environment will use.

Cost and ownership depend on the storage you choose. The object storage bill is paid to your cloud provider under your account and recurs as archived data accumulates, so retention periods, lifecycle rules and access patterns will drive it. Ask any implementation partner for a written quote that covers bucket and access design, identity permissions for the server, verification and restore testing, monitoring of archive failures, and the operating runbook. Ask for the one-time setup separately from the ongoing storage and support work, and confirm which items depend on your server version and deployment method.

Which archival settings fit each storage target

This table compares the two supported archival targets against the service-level and namespace-level settings that control archival. Read each row as a decision point, then confirm the exact setting names, URI format and credential behavior in the official configuration reference for your server version. The main takeaway is that the bucket choice follows your cloud estate, while the identity and deployment checks apply to both targets.

Setting or question	Amazon S3	Google Cloud Storage
When it fits	Your estate already runs on AWS and your team manages buckets and IAM roles in that account.	Your workloads run on Google Cloud and your team manages buckets and service accounts in that project.
Bucket requirements	A dedicated archival bucket with write access for the server, with encryption and retention set by your policy.	A dedicated archival bucket with write access for the server, with encryption and retention set by your policy.
Server identity	An IAM role or credentials for the Temporal server, scoped to the archival bucket only.	A service account for the Temporal server, granted object write access on the archival bucket only.
Credential handling	Prefer workload identity on the host or cluster over static access keys in configuration files.	Prefer an attached service account or workload identity over key files baked into images.
Service-level switch	Confirm the server-level keys that enable archival and set the default target for the cluster.	Confirm the server-level keys that enable archival and set the default target for the cluster.
Namespace-level setting	Confirm which namespaces opt in, and whether a namespace can point to a different target.	Confirm which namespaces opt in, and whether a namespace can point to a different target.
Deployment and Docker	Check the documented Docker restriction before choosing a container deployment for archival.	Check the documented Docker restriction before choosing a container deployment for archival.
Experimental status	Archival is experimental. Confirm the status for your server version before any production use.	Archival is experimental. Confirm the status for your server version before any production use.

Setting up archival at service and namespace level

This sequence takes a self-hosted Temporal cluster from a confirmed server version to archived workflow histories in an S3 or Google Cloud Storage bucket. Each step ends with a check, so you know the service, the namespaces and the bucket agree before you rely on archival.

Confirm server version and archival status
The platform lead records which Temporal Server minor line you run and reads the release notes for that version and its latest patch. Confirm whether archival is marked experimental in those notes, and confirm the documented restriction for Docker-based deployments before you change any configuration. The latest release is v1.32.1, published on October 8, 2026, with patch releases v1.31.4 and v1.30.8 published on October 12, 2026 for earlier lines. Done when the version, the experimental status and the Docker restriction outcome are written down and the team has agreed to proceed.
Prepare bucket and least-privilege credentials
A platform engineer creates a dedicated private bucket for archived histories in S3 or Google Cloud Storage, in the account or project that hosts your Temporal Server, with no public access. Create a service identity that can write, read and list objects in that bucket only, and grant it nothing on other buckets. Keep the credentials in your secrets manager and out of source control. Done when a test write and read succeed with that identity and a write to any other bucket is denied.
Enable archival at the service level
The platform engineer adds the service-level archival settings to the Temporal Server configuration, using the provider and bucket details defined for your server version. Use the documented URI scheme for your storage provider and confirm exact field names against the configuration reference for your version. Apply the change through your deployment method, restart the server services and watch for clean startup. Done when the logs show the archiver initializing without errors and the running configuration matches what you recorded in the first step.
Configure the archival URI on each namespace
For each namespace that should keep archived histories, the namespace owner sets the archival URI to the bucket path planned for that namespace, following the fixed URI format in the documentation. Namespaces without a URI are not set up to archive, so list every namespace in the change record and get sign-off from each owner. Read back the namespace settings with the CLI or API. Done when each in-scope namespace reports its planned URI and each out-of-scope namespace reports none.
Test with a closed workflow and check the object
Run a test workflow in a non-production namespace with archival configured, let it complete and confirm it is closed. Archival depends on the namespace retention period, so confirm in the documentation when a closed history is archived and schedule your check around that timing. Once the object appears, confirm it sits under the expected path, that its size is plausible for the test history, and that the least-privilege identity can read it back. Done when the archived history matches the test workflow and the check is recorded for the change record.

Protecting archived histories in object storage

Archived histories are copies of workflow data that outlive the namespace retention period, so they need the same protection as live executions. The controls below cover the bucket, the identity the server uses to write to it, the lifecycle rules that decide how long data stays, and the Temporal settings that limit who can read it. Confirm each item with your storage provider and against your own environment before go-live.

Bucket access policy and encryption

Restrict the archival bucket so that only the Temporal server identity can write to it and only approved operators can read it. Check that public access is blocked at both the bucket and account level, and that object encryption is enabled with a key your organization manages. Ask your platform team to confirm how S3 or Google Cloud Storage applies these settings to the archival URI, and keep a written list of every principal with read access outside the server. Review that list on a fixed schedule.

Server identity with least privilege

Give the Temporal server its own identity, such as an IAM role or a Google Cloud service account, with permissions limited to writing and reading the archival bucket. Keep that identity away from workers, other services and people, because anyone who can use it can read archived histories. Confirm the exact object actions your provider requires for archival, test them in a non-production bucket, and enable access logging so each read can be traced to a principal.

Retention and deletion rules

Archived histories persist after the namespace retention period ends, so the bucket needs its own lifecycle rules. Decide how long each class of history must be kept, then set expiration or deletion rules to match. Confirm whether versioning or object lock is needed to prevent early deletion, and align the rules with your legal hold and records policy. Test that an expired history is removed as the rule states and that a held history is not.

Payload encryption with a custom codec

Archived histories can contain workflow inputs, results and other payloads that hold personal or regulated data. Bucket encryption protects the stored object, but anyone who can read the object still sees the payload contents in clear form. Plan a custom payload codec for sensitive fields, including how its keys are generated, rotated and stored. Confirm that operators who need decoded history can reach the codec server through approved access paths.

Access controls on the Temporal server

Enable mTLS for frontend and internode traffic, configure a ClaimMapper to map JWT or certificate claims to namespace roles, and set an Authorizer. If no Authorizer is configured, self-hosted Temporal uses the default noopAuthorizer, which allows every API request with no authentication or access control. Treat that as a go-live blocker, and confirm that namespace roles give archival read access only to the people who need it.

Network placement of Temporal services

Temporal services should run on hosts that have no route from the public internet, with network access limited to trusted internal networks. Check that the frontend, the Web UI, the codec server and the path to the archival bucket all stay inside that boundary. Any operator access should go through an internal route with OIDC single sign-on for the Web UI, and your firewall and load balancer rules should be reviewed against this design before launch.

Archival compared with longer retention and exporting histories

Choose among these three options by deciding what the stored history must prove and who must be able to reach it. A longer namespace retention period keeps every closed history in the primary persistence database, so reads stay on the normal Temporal APIs and Web UI. The cost is that the database grows with every workflow you keep, and your team must size, back up and restore that database for the whole retention window. Archival to S3 or Google Cloud Storage moves closed histories out of the primary database after the namespace retention period, which limits database growth while keeping the histories in object storage you control. Exporting through a separate process means building and running a job that reads histories and writes them to a store you design. That gives you full control over format and access, in exchange for owning the pipeline.

Query access differs most between the three. Longer retention keeps histories searchable through the tools operators already use, provided the visibility store is sized for the extra volume. Archived histories are read through a separate path, so test how your team finds, opens and filters an archived execution before depending on it, and confirm the read behavior in the release notes for your server version. An export gives you the query engine of your choice, such as a data warehouse, but only for the fields you chose to export. For compliance evidence, longer retention gives you one system of record to show an assessor. Archival adds a second store, so its bucket policies, access logs, object lock settings and deletion rules become evidence too. Exports add job logs, schema documentation and reconciliation reports that show the copy matches the source.

Cost has three components in every option: primary database storage, object or warehouse storage, and people. Longer retention is a single line item that grows with retention length and workflow volume, and it recurs for as long as the data is kept. Archival adds a one-time setup of the bucket, access roles, service and namespace configuration and restore testing, followed by recurring object storage and request charges, plus data transfer costs when histories are read back. An export adds the initial build and the ongoing maintenance of a pipeline that must keep working through each Temporal upgrade. Storage charges depend on history size, and history size depends on payload size, so measure a sample of your own histories before estimating. For Temporal Cloud, the pay-as-you-go pricing page lists retained storage as its own rate, which shows that retention is priced as storage. Ask any partner to itemize setup, lifecycle configuration, restore testing, runbooks, upgrade impact on the archival path and ongoing support.

Two constraints apply to archival specifically. Confirm the feature's current maturity and any deployment-method restriction for your exact server version before relying on archival as the only retention path, because the topic notes both an experimental status and a Docker restriction. If your payloads are protected with a custom codec, archived or exported data stays encrypted, so the codec and its keys must remain available to whoever reads the history years later. An intact bucket is unreadable without the matching key. A separate export is independent of the archival feature, so it survives changes to that feature, but it inherits the same encryption dependency and needs the same key management plan.

Start with a written retention requirement before choosing a tool. It should state how long each class of history must be kept, how quickly an investigator must retrieve one, who may read it, what an assessor will ask to see and when data must be deleted. Then map each requirement to an option. Short retention periods with frequent lookups usually favor longer retention, long periods with rare retrieval usually favor archival, and specific reporting or format needs point toward exports. Many teams combine two options. DeployOpen can prepare the systems, controls and evidence for a compliance assessment, but independent auditors issue any audit report, so confirm with your assessor which artifacts they will accept before the design is fixed.

Limits to confirm before archival goes into production

Archival is a feature to verify in your own environment, not one to assume from this page. The six checks below cover feature maturity, deployment method, storage addressing, version support, retrieval and upgrades, and each one can block a production plan. Confirm every item against the current Temporal documentation and a test environment you control.

Experimental status and change policy

The archival feature is documented as experimental, which determines whether your change policy allows it near regulated workflow data. Ask your platform owner and risk team to decide whether an experimental feature may run in production, and record any exception with its owner and review date. Re-check the maturity label in the current Temporal docs before each release, because a feature's status can change over time.

Docker deployment restriction

Confirm whether the documented restriction on running archival under Docker applies to the packaging you plan to use. A team that tests with Docker Compose but runs Helm charts or Go binaries in production may still have a gap between the two environments. Ask for the exact wording in the current docs, and test archival on the same deployment method you will run in production.

Fixed archival URI format

Archival destinations are addressed through a URI with a fixed format, so the scheme, bucket name and path must match what the server expects for S3 or Google Cloud Storage. Check the exact format in the current docs before you create buckets or write deployment configuration. Confirm what happens to histories archived under an earlier URI if you later change bucket names, regions or paths.

Server version support by release line

Archival support can differ between Temporal Server minor lines, so confirm it for the exact version you run and for each version in your upgrade path. The release history includes v1.32.1 along with patch releases for earlier lines such as v1.31.4 and v1.30.8. Read the release notes for every line you will pass through, and test the specific version you intend to deploy.

Reading archived histories back

Archiving a history is only half of the requirement, because you also need to retrieve it later. Confirm which tools or APIs read archived histories, and whether the Web UI or CLI can display archived executions after the namespace retention period has passed. Run a retrieval test that loads an archived history into a clean environment, and record who is authorized to read that data and how access is logged.

Interaction with server upgrades

Archival configuration and stored histories must remain usable through every upgrade step. Temporal documents upgrading one minor version at a time, with schema upgrades first when release notes call for them, so check whether the archival settings or storage format change at each step. Include an archived-history read test in every upgrade rehearsal, and keep archival configuration under version control so the same settings reach every environment.

Questions teams ask before archival work starts

How much does Temporal archival to S3 or Google Cloud Storage cost?

The cost comes from storage and from the people who design and test the setup, not from a license fee for the server. Cost components:

Bucket and storage charges: paid to your cloud provider and recurring, driven by how much history you keep, how often it is read back, and the storage class you choose.
Team time: one-time work for testing and access design, plus ongoing effort when you change retention or upgrade the server.
Security review: a one-time review of permissions, encryption and network paths, repeated when the setup changes.

Figures come only from your cloud provider's own pricing and the written quote from your implementation partner. Ask the quote to separate one-time work from recurring work and to list the assumptions behind each line.

How long does Temporal archival setup take on a self-hosted cluster?

Duration depends on the environment and the scope agreed in writing before work starts. The main variables are the number of namespaces to archive, whether bucket, identity and network access already exist, the server version in use, and how many test rounds your security reviewers require. Experimental status adds review time, as explained in the next question. Ask for a plan that lists each environment, each namespace in scope, the test cases for writing and retrieving archived histories, and the approvals needed before production. A quote without that breakdown makes it hard to compare timelines between partners or between your own team and a partner.

Does experimental status change the review effort for archival?

Yes. Experimental status means the behavior of the feature can change between releases, so review must tie to a specific server version rather than to the feature in general. Expect the review to cover the release notes for your exact version, a documented rollback path, monitoring for archival errors, and an explicit decision on whether archival runs in production. Confirm the current maturity label in Temporal's documentation for the version you run, because that label determines how much evidence your risk owner will need. Each server upgrade also means rechecking the archival setup, so plan that effort into the support model from the start.

What does our team need to provide before archival work starts?

Work starts faster when the following inputs are ready before the kickoff:

Access: administrative access to the self-hosted cluster configuration, and a way to reach the hosts where Temporal services run. Temporal's deployment guidance says those services should not be reachable from the public internet.
Storage decisions: the provider (S3 or Google Cloud Storage), the account that owns the bucket, the bucket naming standard, and the identity roles the server will use.
Retention rules: how long histories must be kept, from your records policy or compliance team.
Named owners: someone who approves permissions, someone who approves production changes, and someone who owns the bucket after handover.

If any of these are missing, the schedule usually moves, so confirm them in the scope document.

Can our own engineers set up Temporal archival without outside help?

Yes, if your team already runs self-hosted Temporal and has the cloud storage and identity skills needed to design bucket permissions. The setup has two layers, service-level configuration and namespace-level configuration, followed by a retrieval test. Most gaps appear in three places: access design for the bucket, the security review of the server's authorization settings, and monitoring for an experimental feature. Outside help is most useful when your team needs a documented test record for auditors, has limited time for review, or must upgrade the server while archival is in place. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in infrastructure you control, and it prepares evidence for compliance assessments without issuing audit reports.

What security checks should run before Temporal archival goes live?

Start with authorization. If no Authorizer is configured, self-hosted Temporal uses a default that allows every API request with no authentication or access control, so confirm an Authorizer and a ClaimMapper are set before the archival path is reachable. Then check the bucket: access limited to the identity the Temporal server uses, no public read or write access, encryption at rest and in transit as your provider supports it, and network paths restricted to trusted internal networks. Decide whether payload encryption through a custom codec applies to archived histories, because those histories contain the workflow data your codec protects. Record each check with the person who approved it, since auditors will ask for that evidence.

How do we confirm archived workflow histories can be retrieved?

Test retrieval from the archival location with a workflow whose history is past the namespace retention period, then confirm the returned history is complete and matches the original. Run the test in a non-production environment first, then repeat it in production after go-live and after each server upgrade. Keep the results with the change record, including the server version, the bucket configuration and the person who ran the test. Use the retrieval method described in the setup documentation for your server version, and confirm it with the vendor if the documentation is unclear for your release. A passing test shows the path worked at that moment, so schedule the test again after changes to permissions or retention.

How DeployOpen scopes and supports Temporal archival

DeployOpen treats Temporal archival to S3 or Google Cloud Storage as a scoped piece of work inside your self-hosted Temporal deployment. The engagement starts with the retention needs of each namespace, the storage target and the access model for the bucket. Work is planned in writing before any configuration changes, and it is carried out in infrastructure you control.

How we scope

The written scope lists which namespaces get archival and which keep retention only.
It names the S3 or Google Cloud Storage target, bucket ownership and the identity used to write archives.
Engagements are fixed-scope, and ongoing support is available as a retainer after handover.

How we build

Service-level archival settings and namespace-level archival configuration are set and checked in a non-production cluster first.
The archival URI is treated as a fixed value and agreed with you before any namespace is enabled.
The deployment method is checked against the documented Docker restriction before any build starts.

How we hand over

Documentation records the service and namespace settings, bucket layout, IAM permissions and archival URI used.
Verification notes record how archived histories are checked and retrieved from the chosen bucket.
Your team receives a runbook that states the experimental status and what to monitor.

How we support

Retainers can cover Temporal Server upgrades, one minor version at a time, with archival settings rechecked each step.
Confirm the feature's maturity in your target version's release notes before you plan production use.
Support scope and response expectations are written into the agreement before work starts.