Migrate from Pulumi Cloud to a self-managed backend

How to move Pulumi Cloud stacks to your own backend without losing history

If a renewal, a pricing change, a data residency rule or lock-in is pushing you off Pulumi Cloud, the short answer is that the Pulumi CLI stays and the backend and the services around it change. Your program code, providers and stacks keep working. What you replace is where state lives, who holds the lock, where secrets are decrypted, and who keeps the history. Platform or cloud engineering usually owns this work, with security signing off on the encryption, access and audit design before any production stack moves. Effort and risk depend less on the number of stacks than on how many Pulumi Cloud features your teams use without thinking about them. The state move is the smaller part of the project. DeployOpen plans and implements the backend in your own cloud account or data center, so state, keys and logs stay under your control from the start.

Begin with two decisions: the backend (S3, Azure Blob, GCS, MinIO or PostgreSQL) and the secrets provider. Settle these first, because state holds encrypted configuration values that must still decrypt after the move. Then run pulumi stack migrate against a non-production stack and confirm three things: the target backend holds the state, pulumi preview shows no unexpected changes, and secrets decrypt as expected. Keep a pulumi stack export JSON copy of each stack as a rollback point, stored in encrypted, access-controlled storage with a retention period your auditors have approved. Schedule a freeze so nobody runs an update against a stack while it moves, and confirm with your team how long that freeze must last for your largest stacks.

The services around the state are the larger part of the work. Pulumi Cloud gave you locking, run history, team permissions, policy checks and an audit trail. On a self-managed backend, each one needs a named owner and a test. Test lock behavior with concurrent runs before cutover, because locking depends on the storage and tooling you choose. For history, decide where previews and update logs are archived and who can read them. For access, map each team to IAM roles on the bucket or database, and map the CI identity that runs updates to its own role. Confirm with your security team which events must be logged and where those logs go. Before the first production stack moves, ask any implementation partner for a written list of each replaced control, who operates it and how it is tested.

Which Pulumi Cloud capabilities map to a self-managed backend, and which need rework

This table maps each capability Pulumi Cloud provides to its self-managed equivalent and marks it as clean, needs rework or gap. Read each row as a planning question: a clean row means a standard component covers the need, rework means you build the practice yourself, and a gap means you must confirm the behavior before relying on it. Treat every gap as an open item to verify against current Pulumi documentation and your chosen backend.

Capability	Self-managed equivalent	Status	What to confirm or build
State storage	Object storage (S3, Azure Blob, GCS or MinIO) or PostgreSQL as the stack backend	Clean	Confirm bucket versioning, encryption at rest and a restore test from prior state versions
Locking during updates	Backend-specific locking, such as conditional writes or a PostgreSQL-based lock, depending on the backend	Needs rework	Test concurrent updates in a non-production stack and confirm which backends lock and how stale locks are cleared
Stack history and change log	Object store versions or database history, plus Git history for stack configuration	Needs rework	Keep stack configuration in Git and set retention for state versions to match your audit window
Encrypted secrets	Secrets provider chosen in the CLI, such as a cloud KMS, passphrase or an external key service	Needs rework	Choose the provider per stack, document key ownership and rotation, and confirm how existing encrypted values re-encrypt
Team access control	Access to the bucket or database plus CI-enforced approval for updates	Needs rework	Restrict write access to the CI runner identity and require review before production applies
Audit trail of who changed what	Cloud audit logs on the state store plus CI run logs shipped to external logging	Gap	Confirm which events the store and CI system record and whether they include the operator identity
Drift detection	Scheduled preview and refresh from CI with alerting	Gap	Confirm refresh behavior on your resource types and the limits of scheduled runs described in the drift page
Policy enforcement	Policy-as-code checks in CI before apply	Gap	Confirm the policy tool supports your Pulumi language and that checks cannot be skipped by pipeline edits
Deployment settings and stack configuration	Pipeline definitions and stack config files in version control	Needs rework	Re-create per-stack environment variables and runner settings, since these do not move with the state

What data moves, what gets rebuilt, and which integrations need new wiring

Pulumi's documented export path moves stack state, but much of what Pulumi Cloud held around that state does not travel with it. The cards below separate what you can copy, what you must recreate by hand, and what depends on your own secrets and integrations.

Stack state through pulumi stack export

Stack export produces a JSON copy of each stack's checkpoint, which is the state the engine uses to compute the next update. Run it per stack before you switch backends, store the file in a restricted location, and keep it until a preview against the new backend shows no unexpected changes. Confirm that the export includes the resource graph you expect, since the file itself is the only full copy of that state you will hold outside the service.

Stack migration with pulumi stack migrate

The pulumi stack migrate command moves a stack's state to another backend, such as an object store or a PostgreSQL-backed backend, and is the path that keeps the stack's history intact in the new location. Check the command's current options and supported target backends against the Pulumi documentation for your CLI version, and run a preview immediately after each move. Plan the cutover so no one runs an update from the old location during the move.

Encrypted secrets and the new secrets provider

Secrets in stack configuration are encrypted with a key held by the secrets provider attached to the stack, and that provider does not change when you change the state backend. Confirm in your own environment that the new secrets provider can decrypt values encrypted under the old key before you cut over. If it cannot, the migrated stack will fail on the first run that reads a secret, and the fix is to re-enter those values under the new provider.

Deployment settings and stack configuration

Deployment settings, such as the source repository, branch and environment variables used by Pulumi Deployments, are stored in the service and do not move with the state. Stack configuration files tied to the old backend, including references to Pulumi Cloud organization names, must be reviewed and replaced with values that match your new backend. Record every stack's settings before you start, so you can rebuild each one in your CI system or a new runner.

Policies and team permissions

Policy packs, access roles and team memberships held in Pulumi Cloud have no equivalent in the open-source CLI, so each one must be rebuilt in the new access model. Map every current team and role to a group in your identity provider, and decide which actions, such as update, refresh and state export, each group keeps. Treat this as a design task with your security team, not a copy step, because the old permission model will not carry over automatically.

Webhooks and CI integrations

Webhooks, notifications and pull request integrations that call Pulumi Cloud will stop receiving events after cutover, and CI jobs that authenticate with a Pulumi Cloud access token will fail. Inventory every pipeline and webhook that references the service, then point each one at your new state location and credentials. Test each job end to end, including the job that runs refresh and drift checks, before you retire the old token.

Choosing between S3, Azure Blob, GCS, MinIO and PostgreSQL as the state backend

Amazon S3 is operated by AWS, so your team owns the bucket configuration, IAM policies and any customer-managed encryption keys, while AWS runs the storage. It is usually the lowest-effort choice for teams already running workloads in AWS and already issuing short-lived credentials to CI runners. Confirm the locking behavior in the Pulumi backend documentation for your CLI version before you run concurrent updates, because locking depends on how the Pulumi backend integrates with the bucket.

Operator: AWS runs the service. Your team manages the account boundary, the bucket and the IAM roles that pipelines assume.
Versioning: Enable bucket versioning so earlier state objects can be restored after a bad write. Set retention and lifecycle rules according to your account policies.
Access control: Scope bucket policies to the pipeline role and a small administrative role, and confirm that access logging is enabled for state objects.
Operating burden: Storage itself needs little attention. The recurring work is IAM review, key rotation for any KMS key you manage, and periodic review of access logs.

Check with your cloud security team whether your AWS account policies allow infrastructure state, which can contain resource identifiers and sensitive outputs, to be stored in this account and region.

The migration sequence from inventory to decommissioning Pulumi Cloud

This sequence moves each stack from Pulumi Cloud to a self-managed backend in controlled steps, so every stack is proven on the new backend before its old history is retired. Each step ends with a written artifact that the next step depends on.

Inventory stacks, backends, secrets and CI hooks
The platform or DevOps lead lists every project and stack in Pulumi Cloud, with its current backend, secrets provider, owning team, and the CI pipelines, webhooks and scheduled jobs that run pulumi preview or pulumi up against it. Include the deployment settings, policies and team permissions that the service holds, because they do not move with the state. The output is a stack inventory with one row per stack and a dependency list for each CI hook. The step is done when the security and compliance owners have reviewed the inventory and agreed which stacks are in scope for each wave.
Choose the backend and secrets provider
Select the target backend for each class of stack, such as S3, Azure Blob, GCS, MinIO or PostgreSQL, and a secrets provider that matches your key management policy. Confirm the backend's versioning, encryption at rest, access logging and retention settings against your own requirements, and confirm the current supported behavior of the MinIO community edition with the vendor before relying on it, since its repository is archived. The output is a short architecture decision record covering the backend, the secrets provider, the access model for operators and CI, and the owner of each. Done means the record is approved and the backend's access controls are tested with a non-production identity.
Pilot one non-production stack
Pick a low-risk, non-production stack and export a JSON copy with pulumi stack export as a baseline. Then migrate it to the new backend with pulumi stack migrate, and restore a second copy from the export into a scratch backend to test recovery. Check how encrypted secrets behave in the restored copy, since they depend on the secrets provider you chose. The output is a pilot report that records the commands used, the stack's resource count before and after, and any secrets or configuration that did not carry over. Done means the team has rehearsed the rollback path at least once.
Run both backends in parallel
For each stack in the wave, run pulumi preview against the old and the new backend from the same code revision and compare the outputs. Investigate every difference, including resource ordering, provider versions, config values and secret handling, and do not apply changes to the production stack during this phase. Repeat the comparison on a schedule until the diff is empty for the whole wave. The output is a validated preview diff per stack, signed off by the stack owner. Done means two consecutive comparisons show no unexplained changes.
Cut over each stack in a locked change window
Write a cutover runbook for each stack that lists the freeze on pipeline runs, the final export from Pulumi Cloud, the backend switch, the first preview on the new backend, the post-cutover checks and the rollback steps. Freeze pipeline triggers and manual deployments for the window, then update the CI variables and backend configuration to point at the new backend. The output is a completed runbook with timestamps and the first successful preview on the new backend. Done means the stack has run one successful update on the new backend and the freeze is lifted.
Retire CI hooks and drift jobs
Remove or repoint the Pulumi Cloud webhooks, access tokens and scheduled jobs that the inventory identified, and replace any drift detection or policy checks the service provided with CI-driven preview and refresh jobs and your own policy tooling. Confirm that alerts now reach the team that owns each stack. The output is an updated inventory showing each hook as retired or replaced, with the new job or alert that covers it. Done means no stack still depends on a Pulumi Cloud token or webhook.
Archive history and audit exports before decommissioning
Before any Pulumi Cloud organization is closed, export the stack update history, audit logs and team and access records that your retention policy requires, and store them in your own archive with checksums and access controls. Keep a copy of each stack export taken at cutover. The output is an archived export set with an index that maps each stack and period to its files. Done means the compliance owner confirms the archive is readable and complete, and the decommissioning request is approved in writing.

What drives the cost and duration of the move, and how to keep each one down

This table lists the factors that change how much work the move from Pulumi Cloud to a self-managed backend takes and what it costs to run afterward. Each row explains why a driver moves effort and what reduces it, so you can scope a quote against your own estimate of stacks, secrets and compliance needs.

Driver	Why it moves effort	How to keep it down
Number of stacks and environments	Each stack needs its state exported, imported into the new backend and checked, and each environment adds a separate migration and verification pass.	Group stacks by project, migrate low-risk non-production stacks first, and script the export and import steps so they repeat without manual work.
Secrets volume and provider choice	Encrypted secrets in stack configuration must be re-encrypted under the new secrets provider, and the key management model you pick determines who can decrypt them.	Inventory secrets before the move, retire unused values, and choose a provider your team already operates, such as a cloud KMS or an existing vault.
Number of CI pipelines and integrations	Pulumi Cloud often triggers previews, updates and webhooks from pipelines, and each pipeline needs its credentials and backend settings changed.	Count pipelines and integrations up front, centralize backend login in a shared template, and switch pipelines in batches with a rollback path.
Compliance evidence needs	Assessors often ask for access logs, retention periods and encryption of state, and the service provided some of this history that you must now produce yourself.	Agree the evidence list with your auditor before building, then configure bucket or database logging, retention and encryption to produce it by default.
Backend operations: backups and upgrades	Object storage needs versioning and backup policies, and PostgreSQL needs regular minor updates and planned major upgrades, all of which recur.	Enable object versioning or point-in-time recovery, and document the PostgreSQL support window so upgrades are scheduled ahead of end of life.
MinIO support model	The MinIO community repositories are archived and the community server is distributed as source only, so patching and support come from your team or a commercial contract.	Confirm the support model and license obligations in writing before choosing MinIO, or prefer a cloud bucket or PostgreSQL backend if you need supported updates.
Team Pulumi experience	Engineers unfamiliar with managing state locks, stack migration and provider secrets need more review time and may make recovery errors during a partial failure.	Run a pilot on one stack, write runbooks for lock recovery and restore, and pair each migration with a reviewer who has run it before.
One-time versus recurring work	One-time work covers the pilot, migration, pipeline changes and runbooks, while recurring work covers backups, PostgreSQL and MinIO upgrades, monitoring and on-call.	Ask the quote to split one-time and recurring items and to state who owns each recurring task after handover.

What usually goes wrong when stacks leave Pulumi Cloud

Most failed moves off Pulumi Cloud fail in the same few places: secrets that cannot be decrypted, two backends drifting apart during the parallel run, and protections the service provided without anyone noticing. Each card below names one risk, the prevention step to take before cutover, and the check to run before you retire the hosted stack.

Losing access to encrypted secrets

Pulumi Cloud encrypts stack secrets with a key it manages, so moving the state file alone does not carry the ability to read them. Before cutover, choose the new secrets provider (a cloud KMS, Vault-compatible service or passphrase) and confirm that a stack created on it can decrypt and plan without the Pulumi Cloud service. Keep a tested recovery path for the key, since a lost key makes every stored secret unreadable. Check that a preview on a copied stack shows no decryption errors.

Drift between old and new backends

During the parallel run, a stack may be updated in both places, and the two states then disagree about what exists. Freeze deployments to the stack in one backend, migrate it, and record the state serial before and after. Run a refresh and preview against the new backend and compare the resource list with the last Pulumi Cloud snapshot. Do not resume updates on the old backend until the comparison is clean.

Missing locks allowing concurrent updates

Pulumi Cloud serializes updates to a stack, and a self-managed backend does not inherit that guarantee automatically. Object storage backends in particular offer no lock that Pulumi will honor on its own, so two CI jobs can write state at the same time. Enforce one update path per stack, such as a single CI workflow with a concurrency group, and restrict direct CLI access to production stacks. Confirm the behavior by starting two updates on a test stack and checking that the second one waits or fails.

Lost history and audit trails

Pulumi Cloud keeps update history, who ran each change and the diffs that were applied. A plain state file keeps none of that, so the first audit question after migration can go unanswered. Route every update through CI with logged runs, retain the plan output and export the stack history you need before leaving the service. Check that you can name the author, time and approval for the last ten production updates from your own logs.

Backend without backups or versioning

A bucket or database holding state becomes a single point of failure once the service is gone. Turn on object versioning for state buckets or enable point-in-time recovery and continuous archiving for PostgreSQL, and store copies in a second account or region. Test a restore of one stack into a scratch environment. Without that test, you only know that backups exist, not that they can rebuild infrastructure.

PostgreSQL versions reaching end of support

A PostgreSQL backend you run yourself carries its own lifecycle. Pick a major version with support that outlasts your planned use, and schedule minor updates so you stay on supported releases. Check the version your database runs today against the published versioning policy and the end-of-support dates for each release. Plan the major upgrade path, such as logical replication or pg_upgrade, before the version you chose loses support.

Unreviewed MinIO licensing and archived repositories

If you choose MinIO as the object store, review its current status before depending on it. The community server is AGPLv3, the repositories are archived and the README says it is no longer maintained and points to AIStor editions. Confirm with your legal team what AGPLv3 obligations apply to your use, decide whether you will build from source yourself, and document who patches it after an advisory. Check that your deployment can move to another S3-compatible store without changing Pulumi backend configuration.

How the migration differs for a small team, a regulated enterprise and a multi-cloud estate

A small team with a handful of stacks in one cloud usually has the simplest path. The main work is choosing one backend, moving each stack with pulumi stack migrate, and replacing the locking and history that the service provided. Because few people touch the stacks, the team can often run the move in one window and keep the old backend read-only for a short period as a fallback.

Backend choice: A single object store in the same cloud account as the workloads is usually the least moving-part option. Confirm how the store is versioned, since version history is what replaces the service's state history.
Locking: Pulumi's file and object backends do not give the same concurrency protection the hosted service gave. Agree on a rule, such as one CI pipeline runs updates per stack, and write it down.
Secrets: Decide early whether stack secrets move to a cloud key service or a passphrase. Test decryption on every stack before you retire the old copy.
Access: Replace the hosted team permissions with cloud IAM on the bucket and the CI credentials, and remove shared personal logins.
Sequencing: Migrate a non-production stack first, run a preview, then move production stacks one at a time.

Before cutover, confirm with your Pulumi contact exactly which settings, webhooks and policies do not transfer, and rebuild each one by hand.

Questions buyers ask before moving off Pulumi Cloud

How much does it cost to move off Pulumi Cloud?

The cost depends on the components you replace, not on a single figure. Pulumi Cloud charges stop, but you take on storage for state, a key management service or other secrets provider, CI runner time for previews and updates, and the one-time engineering work to migrate stacks and rebuild audit and access controls. Recurring costs include storage, key management, runner minutes, backups, database hosting if you choose PostgreSQL, and the people who patch and monitor the backend. Costs go up with the number of stacks, the number of environments and how often you run drift checks. Ask any quote for a line-item breakdown that separates one-time migration work from recurring operations, names who pays for each item, and states which Pulumi Cloud features the price assumes you will no longer use.

How long does a migration off Pulumi Cloud take?

The timeline is set by the size and state of your estate, not by the CLI itself. The main drivers are the number of stacks, how many use encrypted configuration, how many CI pipelines call Pulumi Cloud, whether drift detection runs there today, and how many teams need new access rules. Moving a stack with pulumi stack migrate is the quick part. Verification, parallel runs and a rollback window take longer. Ask for a timeline that lists the stacks in scope, the cutover order, the verification steps for each stack and the point at which Pulumi Cloud access is withdrawn. A written scope lets both sides agree on those dates before work starts.

What does our team need to provide for the move?

Your team supplies the facts and decisions that no vendor can make for you. The list is short but each item affects scope:

An inventory of stacks, projects, CI pipelines and the people who run them today
A cloud account or data center location, network path and naming standard for the new backend
A named owner for the secrets provider and its keys
Decisions on who may read, update and approve state, mapped to your identity provider groups
A rollback plan and a date after which Pulumi Cloud is no longer the source of record
Sign-off from security and compliance on where state and secrets will be stored

Missing items usually show up as delays during cutover, so confirm them before the scope is written.

Can our engineers move the stacks ourselves?

Yes, a team with Pulumi and cloud experience can migrate its own stacks, especially a small estate with few secrets. The harder work is everything around the migration. Your team would need to design backend high availability and backups, rebuild locking and an audit trail, set up access control to replace the team features you had in Pulumi Cloud, and decide how drift checks run from CI. Outside help is most useful for that design work, for hardening the backend, for documenting controls and for supporting you after cutover. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted platforms in your own infrastructure under a written scope, and ongoing support is available as a retainer. DeployOpen prepares evidence for compliance assessments, but independent auditors issue any reports.

Do encrypted secrets survive the move to a self-managed backend?

They can, but you should not assume they will. Whether an encrypted value still decrypts depends on the secrets provider each stack uses, on whether that provider stays available after the move, and on whether changing the provider re-encrypts values. Before cutover, confirm for each stack which provider it uses, run a migration on a copy, and check that the copied stack previews and decrypts its configuration. Keep the original Pulumi Cloud copy until the copy has passed those checks. Also confirm how the new backend will hold the key material, who can read it and how it is rotated. Record the answers as part of the migration evidence.

Which backend should we choose: S3, Azure Blob, GCS, MinIO or PostgreSQL?

Choose the backend that your team can operate, back up and secure in the environment you already run. An object store in the same cloud as your workloads is usually the simplest path, and PostgreSQL suits teams that want a relational store with well-documented high availability and upgrade paths. PostgreSQL is released under a permissive license, and version 14 is supported until November 12, 2026, while version 18 is supported until November 14, 2030, according to the PostgreSQL versioning policy. MinIO needs more caution. Its README says the repository is no longer maintained, the community edition is distributed as source only, and support is best effort. Confirm how your chosen backend handles locking, versioning and backups before you commit.

What operations does a self-managed backend need that Pulumi Cloud handled for us?

You take on locking, state history, backups, access control, patching and failover. Confirm each item for your chosen backend before cutover. For PostgreSQL, minor releases replace executables and restart the server, major upgrades can use logical replication to keep downtime to several seconds, and point-in-time recovery depends on continuous archiving you configure. Hot standby servers can serve read-only queries, but PostgreSQL does not detect a failed primary or notify a standby, so automatic failover needs external tools. A connection pooler such as PgBouncer is often part of the design. For object storage, confirm how versioning, object locking and retention work in your cloud. Document the answers in your runbook, and test a restore before you rely on the backend.

How DeployOpen scopes, runs and supports the move

DeployOpen plans and implements the move from Pulumi Cloud to a self-managed state backend inside your own cloud accounts, data centers or air-gapped network. Each engagement starts from a written scope that covers the backend, stack migration, secrets provider and the controls that replace what the service provided.

How we scope

Inventory every stack, its state size, secrets configuration and the CI jobs that call the Pulumi CLI today
Agree the target backend (S3, Azure Blob, GCS, MinIO or PostgreSQL) and the secrets provider in writing before work starts
Define the replacements for locking, history, access control and audit trails as named deliverables with acceptance criteria

How we build

Provision the state backend, encryption keys and access policies in your environment, then rehearse stack migration on non-production stacks
Rebuild team permissions, CI pipelines and preview and refresh jobs against the new backend and record each change
Test recovery from a failed or interrupted update, and test that the restricted roles can read and write only the stacks they own

How we hand over

Deliver runbooks for backups, state recovery, key rotation and adding or retiring stacks, written for your platform team
Document the controls and evidence produced, so your auditors can review them, noting that DeployOpen prepares evidence but does not issue attestations
Walk your engineers through cutover and rollback steps, and confirm the handover checklist against the agreed scope

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins
Ongoing support, upgrades of the backend and CLI, and continuous testing are available as a retainer
Confirm with DeployOpen during scoping which support hours, response paths and upgrade windows the retainer includes

Move from Pulumi Cloud to a self-managed state backend