How do you export your stacks from Pulumi Cloud without losing control of state?
Stack state and configuration can leave Pulumi Cloud through documented Pulumi CLI paths, but the hosted features around them do not come along with the export. A renewal, a billing change or a data residency rule is usually what forces the move, so plan the exit as a sequence of checked steps. This page covers what moves, what stays behind and the order of work. Before you run any command, confirm its exact behavior against Pulumi's current documentation for the CLI version your team uses, because flags and backend options can change between releases. Use the commands named here as the starting point for your runbook and test them in a non-production project first.
Two CLI paths carry the stack itself. pulumi stack export writes the stack's state to a JSON file, which gives you a readable, point-in-time copy for review, backup and restore testing. pulumi stack migrate moves a stack to another backend, such as object storage or a database, so that backend becomes the state location your CI jobs use. Secrets need separate attention. Values in state are encrypted by the stack's secrets provider, and for stacks on Pulumi Cloud that provider is the service itself. Before cutover, confirm in Pulumi's documentation whether the encrypted values move intact, which provider or key decrypts them afterward and whether a restore test can read them. If you lose access to that key, you lose the secrets, so rehearse this step first.
Expect deployment settings configured in the service, policy packs, team and role permissions, scheduled drift checks and the audit history the service kept to stay behind. Record each one from the console before you disable anything, then rebuild it in your CI system or identity provider. Work in this order: inventory every stack and its secrets provider, save JSON exports into access-controlled storage, migrate one non-production stack and run a preview against the new backend that shows no unexpected changes, then move production stacks and update CI credentials. Cancel the subscription only after a restore test from your exported copies passes.
Which Pulumi Cloud data can you export, and how?
This table compares the three kinds of data you need to move out of Pulumi Cloud: stack state, configuration in source control, and the project and stack names used to recreate each stack. Read each row for the export method, the output format and the points you must confirm in your own environment before relying on the copy. The main takeaway is that state can be moved, but the service-side settings around it need to be rebuilt by hand.
| Data type | Export method | Output format | Limits and what to confirm |
|---|---|---|---|
| Stack state | pulumi stack export to a JSON file, or pulumi stack migrate to a new backend | JSON state file from stack export; the migrate command moves the stack's history and state to the target backend | Confirm whether secrets in the state are exported encrypted or decrypted for your setup, and where the file is stored after export. Test a restore in a non-production stack first. |
| Stack configuration files | Copy from the project's source repository (for example, Pulumi.<stack>.yaml files) | YAML files kept in version control, already in the format the Pulumi CLI reads | Configuration values that were set with pulumi config and encrypted secrets must be checked for their encryption method. Confirm the secrets provider used by each stack before you copy the files. |
| Project name | Read from the Pulumi.yaml file in the project repository | Plain text name in the project file | Confirm the name matches what the new backend expects, since it is part of the stack reference used during migration. |
| Stack names | List with pulumi stack ls in the current backend, and record each name before migration | Plain text list of stack names, typically in the form organization/project/stack | Organization and team scope do not carry over as part of the stack name. Record each stack name and map it to its new location in the target backend. |
| Deployment settings and policies | Not exported by the CLI; recreate them from your own records or CI configuration | Not applicable: no export file is produced | Scheduled jobs, policy packs and drift settings tied to the hosted service must be rebuilt on your own CI or policy tooling. Ask Pulumi for any export tool before assuming one exists. |
| Team permissions and audit history | Not exported by the CLI; capture access lists and audit records from the service before cancelling | Not applicable: no export file is produced | Record who had access to each stack and project while the service is still active. Plan how the new backend will provide access control and audit trails. |
What does not move with the stacks, and how to rebuild it
Stack state and configuration can be copied out, but several operational features live only inside the hosted service. Inventory each item below before your contract ends, because the service may not keep them available afterward, and plan a replacement for each one before you cut over.
Deployment settings
Per-stack settings such as environment variables, deployment configuration, and the source repository link are stored in Pulumi Cloud rather than in the stack files. Export them from the console or API and record each value in your repository, typically as stack configuration files and CI variables. Check that every stack has a matching pipeline definition, since a missing trigger means changes stop applying silently after cutover.
Policies and compliance rules
Policy packs enforced through Pulumi Cloud, such as CrossGuard rules applied to previews and updates, do not transfer with the stacks. Rewrite the rules as policy code in your repository and run them as a required CI check on every preview. Confirm which policy packs are enforced today, which are advisory, and who can change them, because a policy that stops running after migration is a control gap that no one may notice.
Team and role permissions
Organization members, teams, and role assignments on each stack are managed in the hosted service and will not appear in your new backend. Map each role to the access control of the target system, such as bucket policies, database roles, or repository permissions, and to CI environment approvals. Record who holds production update rights today so that the same people, and no others, can apply changes after the move.
Audit and update history
The update history and audit trail for each stack are kept by the service, and your stack export contains only the current state, not the history of who changed what. Before the contract ends, export the available history and archive it with your existing logs, and make sure CI run logs and commit records are retained under your own retention policy. Confirm with Pulumi what history is available in an export and for how long, since this record often supports audit evidence.
Scheduled drift detection and webhooks
Scheduled drift checks, alerts, and webhooks or integrations that notify Slack, ticketing, or other tools are configured inside the hosted service. Replace the schedule with a nightly preview-and-refresh job in CI, route its output to your alerting system, and re-create each webhook as a pipeline notification. Test that an injected change produces an alert before you decommission the hosted integration, since a silent drift job is harder to detect than a failed one.
What happens to encrypted secrets during the move?
Secrets in a Pulumi stack are stored as ciphertext in the stack configuration and state, and they are encrypted with the secrets provider the stack was created with. Whether they move cleanly depends on two things: which provider the stack uses, and whether the export you take keeps those values encrypted rather than decrypting them into plain text. Before you run pulumi stack export or pulumi stack migrate, open each stack's configuration and record its secrets provider. Do not assume the answer is the same for every stack in the organization, because stacks created at different times or by different teams can use different providers.
You face a clear decision for each stack. Option one is to keep the existing key or provider reachable from the new backend, so the ciphertext remains readable without changing any values. That means the destination environment must have access to the same key material, for example through the same cloud KMS key or the same passphrase-based setup, and the access policies must allow the CI runners and operators who will run updates. Option two is to create a new secrets provider and re-enter each secret value from a trusted source. This is slower and touches every secret, but it removes the dependency on the old key once the migration is done. Choose one approach per stack, write the decision down, and confirm the identities that need decrypt rights before cutover.
A copy of the state without access to the matching key is not usable. The state file can be moved successfully and still fail the first time a program reads a secret, which often surfaces only during a deployment. Test decryption on a copy of the exported stack in an isolated environment before any production cutover: run a preview that reads every secret-dependent resource, confirm that no value comes back as an error or as an unexpected placeholder, and keep the export and the key access records together under your change control. Confirm the exact export format and encryption behavior for your CLI version against the Pulumi documentation, since this page does not state provider-specific behavior.
What is the sequence for a complete export from Pulumi Cloud?
The sequence produces a verified JSON copy of every stack, a record of the secrets and access model to rebuild, and a working target backend that CI and developers use in place of Pulumi Cloud.
Inventory stacks, secrets providers and team roles
Before touching any stack, the platform owner lists every project and stack in the Pulumi Cloud organization, the secrets provider each stack uses, the access tokens and CI integrations that call the service, and the team roles that grant access. Record this in a spreadsheet or repository file that the team can review. The step is done when every stack appears on the list with an owner, a secrets provider and the pipelines that deploy it, and someone other than the author has checked the list against the Pulumi Cloud console.
Freeze changes on each stack
Ask the teams that own each stack to stop deployments and pause scheduled runs, drift checks and automated previews from CI until the export is verified. Confirm that no update is in progress in the console and that no pipeline is queued against the stack. This keeps the exported state consistent with the resources it describes. The step is done when the owners confirm the freeze in writing and the stack shows no pending or running updates.
Export each stack to a JSON file
Using the Pulumi CLI with the correct organization and stack selected, the operator runs pulumi stack export to write each stack's state to a JSON file, and stores these files in a versioned, access-controlled location separate from Pulumi Cloud. Name each file with the project, stack and export date so it can be traced later. Check that the file parses as valid JSON and that the resource count matches what the console reports. The step is done when every stack has a file in the archive that passes both checks.
Choose the target backend and move state
The team selects the new backend, such as an object storage bucket, Azure Blob, Google Cloud Storage, MinIO or PostgreSQL, and confirms that it supports locking, encryption and the access model the organization requires. Then it runs pulumi stack migrate to move each stack to the new backend, or imports the JSON file into the new backend when a direct migration is not practical. Ask the vendor or the Pulumi documentation which options apply to your CLI version. The step is done when each stack reports the new backend URL and the stack history is present there.
Verify the copy before cutover
Run pulumi preview against each migrated stack from a workstation or CI runner that points only at the new backend. A preview with no unexpected changes shows that the state matches the live cloud resources. Compare the resource count and outputs with the archived JSON, and confirm that secrets decrypt with the chosen secrets provider. Remember that encrypted secrets only move if the new provider can decrypt them, so test a sample value. The step is done when every stack previews cleanly and the team signs off on the comparison.
Point CI and developers at the new backend
Update pipeline variables, backend configuration and developer environment setup so that every deploy, preview and local run uses the new backend and the new secrets provider. Re-create the access controls the old roles provided, such as who can deploy to production, because team permissions and deployment settings do not move with the state. Keep the Pulumi Cloud organization read-only until the team is satisfied, and then revoke access tokens. The step is done when a test deployment succeeds on each pipeline and no pipeline still references the old backend.
Which target backend should hold the exported state?
PostgreSQL is a common choice when a team already operates database services and wants stack state in a system it knows how to back up, restore and audit. It is released under the PostgreSQL License, a liberal open source license similar to the BSD or MIT licenses, so there is no license fee and no usage restriction to track. The project ships a new major version about once a year and supports each major version for five years. Per the PostgreSQL versioning policy, the supported major versions and end dates are 18 (final release November 14, 2030), 17 (to November 8, 2029), 16 (to November 9, 2028), 15 (to November 11, 2027) and 14 (to November 12, 2026). Versions 13 and earlier are unsupported.
- License: The PostgreSQL License permits commercial use, modification and redistribution without royalties.
- Supported versions: Confirm which major version your platform team will standardize on and plan the upgrade path before the end date.
- Failover: PostgreSQL supports hot standby and synchronous or asynchronous replication, but it does not detect a primary failure. Automatic failover requires external tools.
- Upgrades: Minor releases replace executables and restart, while major upgrades use dump and restore, pg_upgrade or logical replication.
- Operating cost: You pay for servers, storage, backups, monitoring and the staff who patch and restore the cluster.
Confirm with your database team that the backend cluster has tested backup and point-in-time recovery before you rely on it for state.
MinIO provides S3-compatible object storage that you can run inside your own network, which suits teams that want an S3 backend without a public cloud account. Before you choose it, understand the project's current status. The minio/minio, minio/operator and minio/mc GitHub repositories are archived and read-only. The README states that the repository is no longer maintained and points to AIStor Free and AIStor Enterprise as alternatives. The community server is licensed under the GNU AGPL v3.0, and the project distributes the community edition as source code only, with no further pre-compiled binary releases.
- Archived repositories: The last tagged community release is RELEASE.2025-10-15T17-29-55Z, and legacy binaries will not receive updates.
- Source-only builds: You build the server yourself with Go 1.24 or later or from the provided Dockerfile, and you own that pipeline.
- AGPLv3 obligations: Have legal review how the AGPL applies to your use, especially if you modify the server or offer it to other parties.
- AIStor decision: Decide whether you want AIStor Free or AIStor Enterprise, which carries commercial support, or whether you accept best-effort community support through GitHub and Slack.
- Security patching: Plan who tracks upstream fixes once no new community binaries appear.
Confirm the license position and the support model with your legal and procurement teams before you select MinIO as a long-term state store.
A cloud object store, such as S3, Azure Blob Storage or Google Cloud Storage, is often the simplest backend when your organization already holds a contract with that provider and runs its workloads there. Pulumi supports these as self-managed state backends, and the storage, encryption and access controls sit inside an account your security team already governs. The choice depends mostly on the cloud contract your team already holds and on the locking and versioning behavior you need, both of which you must confirm for your setup.
- Existing contract: Storage and request charges usually land on an account you already pay for, so confirm whether the enterprise agreement covers the new spend.
- Versioning: Confirm that object versioning is enabled so that earlier state files can be recovered after an accidental overwrite.
- Locking: Confirm how concurrent updates are prevented for your chosen backend and test it with two simultaneous previews.
- Access control: Map who can read state, since state can contain sensitive values, and restrict those roles separately from pipeline roles.
- Data residency: Confirm the region in which the bucket or container is created, because it determines where state physically resides.
Before you migrate, ask your cloud team to demonstrate a restore of a deleted state object in a test account.
How do you verify the copy before you cut over?
Treat the export as untrusted until it passes four checks. First, store each pulumi stack export JSON file with a checksum (SHA-256 is a sensible choice) and keep the hash list outside the bucket that holds the copy, so a later edit is detectable. Second, confirm that the new backend lists every stack you expect, matching names, organizations and project paths against an inventory you build from the Pulumi Cloud console before you start. A missing stack is easy to overlook when the migration command reports success for the ones it moved.
Third, run pulumi preview on each stack from the new backend against the live cloud resources. A clean migration should produce no changes you cannot explain. Any proposed create, replace or delete needs a root cause before cutover, because it usually means the state, the program or the provider version drifted apart. Fourth, test that secrets decrypt. Use pulumi config get on a sample of secret keys from each stack, from a runner that has only the new secrets provider's access, and confirm the values match what the team expects. Confirm with your own secrets provider team how key rotation and access grants will work after the move, since the Pulumi Cloud service no longer holds those keys.
Keep Pulumi Cloud read-only for a period after the new backend takes over, so you can compare outputs, previews and history against the new system and roll back if something was missed. Do not block writes to the hosted service before this comparison is complete. The exact retention period depends on your Pulumi Cloud contract and your internal data retention rules, so confirm both with Pulumi and your compliance owner before you schedule the cutover, and record the date on which the hosted copy will be decommissioned.
What to plan before the Pulumi Cloud contract renews or ends
Exporting stacks is the technical part of leaving Pulumi Cloud. The decisions around it, including timing, sign-off, audit access, team communication and credentials, decide whether the cutover is clean. Work through these cards before the contract end date, not after the last hosted run.
Export timeline against the renewal notice
Start the export work well before any renewal or termination notice deadline, because the notice period in your order form controls when you must decide. Confirm the notice period, the last day of service access and whether data remains readable after termination. Migrating stacks, rerunning a preview on the new backend and comparing outputs takes longer than most teams expect, so schedule a dry run on a non-production stack first.
Sign-off for the new backend and secrets
Name one owner who approves the new state backend and the secrets provider before any stack moves. Security, platform and compliance should each review where state files, which contain resource details, will be stored and who can read them. Record the decision, because the approver is the person auditors will ask about when reviewing the change.
Read access for audit evidence
Keep read access to Pulumi Cloud for auditors and internal reviewers after the last stack moves. Confirm with Pulumi how long read-only access and stack history remain available after your subscription ends, and export the update history you need as a copy you control. Ask your auditor which evidence they expect, such as past previews, approvals and state versions, before the account is closed.
Cutover communication to engineering teams
Tell every team that deploys with Pulumi which stacks move, on what date, and what changes in their daily commands, such as the backend login and the locking behavior. Publish a short runbook covering who to contact when a preview fails during the move. An illustrative example: a team that still runs pulumi up against the hosted backend after its stack has moved will see errors, so freeze deployments on each stack during its window.
CI credentials and tokens to rotate
List every access token that pipelines and developers use to reach Pulumi Cloud, including the access token in CI variables, service accounts and any cloud credentials tied to hosted OIDC trust. Revoke Pulumi access tokens only after the last pipeline has switched to the new backend, and rotate the cloud credentials that the new backend and secrets provider need. Keep the old tokens in a documented revocation list for your change record.
Keeping the history audits need
A stack export captures state, not the surrounding record of who ran what and why. Decide where update history, pull request reviews, deployment logs and policy results will live after cutover, and make sure the CI system retains them for your audit period. Confirm which of these records Pulumi Cloud keeps and for how long, and document any gap before the account closes.
What do teams ask before exporting from Pulumi Cloud?
How much effort does a full export from Pulumi Cloud take?
The effort depends mostly on how many stacks you run, how many resources each stack manages, and how tightly your CI pipelines depend on the Pulumi Cloud backend. A team with a handful of stacks, one secrets provider and pipelines that only call the CLI can move in a small, contained change. A team with dozens of stacks, cross-stack references, and pipelines that read Pulumi Cloud settings or environment configuration will spend most of its time on inventory, testing and cutover. Ask any provider for a written inventory of stacks, dependencies and pipeline touchpoints before agreeing on scope, since that inventory is what the estimate should rest on.
Can our team export stacks alone with the Pulumi CLI?
Yes, many teams can handle the core steps with the open-source Pulumi CLI. The main commands are pulumi stack export for a JSON copy of a stack's state and pulumi stack migrate for moving a stack to another backend. Doing this alone works best when a small group owns the stacks, has tested the process in a non-production project, and keeps a dated copy of every exported file. The harder parts are rarely the commands themselves. They are coordinating a freeze on changes during cutover, updating pipelines, and proving that the new backend holds the same state before anyone runs an update against it.
What does the export need from engineering, security and finance?
Engineering owns the stack inventory, the state migration, pipeline changes and post-cutover checks. Security owns the new secrets provider, key custody, access rules for the new backend and the decision on who may decrypt secrets. Finance needs to know which Pulumi Cloud charges stop, which costs begin (storage, a secrets key service, runner time, and staff time for drift and audit work), and whether a parallel run period is budgeted. Ask any outside provider to name who on your side signs off each stage, so that a stalled decision in one group does not hold up the others.
Do the history and audit trail move with the stacks?
Do not assume they do. A stack export captures the current state, not the full record of past updates, who approved them, or how the stack changed over time. Deployment settings, policies and team permissions are also outside the stack state and need to be recreated in the new environment. Before you start, confirm with Pulumi which history and audit data can be downloaded, and in what format. Then archive that data separately, and map each control you relied on in the service, such as access reviews and change records, to a replacement process that you can show to an auditor.
What happens to encrypted secrets if we lose the encryption key?
Encrypted secrets in a stack export can only be read with the key material of the secrets provider that encrypted them. If that key is lost or cannot be reached after the move, the secrets in the exported state cannot be decrypted, and the stack may fail until those values are re-entered. Before any cutover, confirm with Pulumi how your stacks' secrets are protected, whether you can obtain the key material or re-encrypt values under a provider you control, and where that material will be stored. Test decryption against a copy of the new backend before you retire the old one, and keep a documented recovery path for the new key.
When is outside help worth paying for during an export?
Outside help is worth considering when the stack count is high, when secrets handling needs a design decision, or when your compliance evidence depends on history that must be preserved. It is also useful when your team lacks the time to run a parallel period safely. DeployOpen plans, implements and documents self-hosted platforms inside your own infrastructure, and can run security testing and prepare evidence for compliance assessments, but it does not issue audit reports or certifications. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.
How DeployOpen scopes and delivers a Pulumi Cloud exit
DeployOpen is a Chainscore Labs company that plans, implements, documents and supports self-hosted open-source platforms in your own infrastructure. For a Pulumi Cloud exit, we start from a written scope that inventories stacks, backends, secrets and team access before any state is moved.
How we scope
- Inventory every stack, its backend, and the secrets provider each stack uses today
- Record which Pulumi Cloud features are in use, such as deployment settings, policies and team permissions
- Agree in writing which stacks move, which are retired, and the target backend and secrets provider
How we build
- Stand up the target state backend in your own account or data center, with access controls and encryption configured
- Rehearse pulumi stack migrate and stack export on non-production stacks, then compare resource counts and outputs
- Rebuild deployment pipelines, locking and approval steps in your CI system and test them before cutover
How we hand over
- Deliver runbooks for migrating each stack, rolling back, and recovering state from backups
- Document where secrets now live, who holds the keys, and how rotation is handled after the exit
- Provide a cutover checklist and a record of the tests run, so your team can repeat the process
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing of the new backend are available as a retainer
- Ask any provider, including us, to quote from the written scope, listing one-time migration work and recurring operations separately
