🧱 Pulumi Error: 'the stack is currently locked' Another Update In Progress

Exact Error Message

error: the stack is currently locked by 1 lock(s). Either wait for the other
    process(es) to end or delete the lock file with `pulumi cancel`.
  <backend-url>/.pulumi/locks/organization/myproj/dev/<uuid>.json:
    created by dev@runner-7 (pid 4821) at 2026-07-17T09:14:02Z, requires operation
    is being performed by another process

You may also see error: [409] Conflict: Another update is currently in progress when using Pulumi Cloud, or conflict: the stack is already being updated by .... All indicate the same thing: the stack lock is held.

What It Means

Pulumi takes an exclusive lock on a stack for the duration of any mutating operation (up, destroy, refresh, import). This prevents two concurrent updates from corrupting the same state file. The lock is a small record in the backend — a locks/.../<uuid>.json object for self-managed backends, or a server-side lock in Pulumi Cloud.

If another operation is genuinely running (a teammate, a CI job, an Automation API process), you must wait for it to finish. If a previous operation crashed, was killed, or lost network mid-run, the lock can be left behind as a stale lock that no live process owns — and it must be cleared before you can proceed.

Common Causes

• A real concurrent operation: two people or two CI pipelines running pulumi up against the same stack.
• A previous pulumi up/destroy was killed (Ctrl-C twice, OOM, runner timeout) and never released the lock.
• A network partition dropped the connection to Pulumi Cloud or the self-managed backend mid-update.
• An Automation API program crashed while an operation was inflight.
• Overlapping scheduled jobs (e.g. a cron deploy overlapping a manual one).

Diagnostic Commands

See which stack and backend you are pointed at:

pulumi stack --show-urns
pulumi whoami -v

Inspect the lock details reported in the error — for a self-managed backend you can list the lock objects directly:

# S3 self-managed backend example
aws s3 ls s3://my-pulumi-state/.pulumi/locks/organization/myproj/dev/

Confirm whether a real process still holds it. Check your CI system for a running job, and on the reported host check the PID from the message:

ps -p 4821 -o pid,cmd

If the PID does not exist and no CI job is running, the lock is stale.

Step-by-Step Resolution

1. First, determine whether a real update is running. Check CI, teammates, and any Automation API service. Never cancel a lock that a live operation owns — that risks corrupting state.

2. If a legitimate operation is in progress, simply wait for it to finish and re-run your command.

3. If you have confirmed the lock is stale (the owning PID/host is gone and no CI job is active), clear it with the built-in command, which removes the lock without touching resources:

pulumi cancel --stack dev

This will irreversibly cancel the currently running update for 'dev'!
Please confirm that this is what you'd like to do by typing ("dev"): dev
The currently running update for 'dev' has been canceled!

4. Verify the lock is gone and the stack is readable:

pulumi stack --stack dev

5. Run a refresh before your next change so state reflects reality after the interrupted run:

pulumi refresh --stack dev

6. Re-run the original operation:

pulumi up --stack dev

7. If pulumi cancel reports there is nothing to cancel but the lock file still exists on a self-managed backend, delete only the specific <uuid>.json lock object (not the state file) after triple-checking no process owns it.

Prevention

• Serialize deployments per stack: use a CI concurrency group so only one pipeline touches a given stack at a time.
• Give CI jobs a generous timeout and a trap that runs pulumi cancel on abnormal exit, so a killed runner does not leave a stale lock.
• Avoid Ctrl-C spamming; a single interrupt lets Pulumi shut down cleanly and release the lock.
• Use separate stacks per environment so unrelated deploys never contend for the same lock.
• For Automation API services, wrap operations so a crash triggers a controlled cancel/refresh on restart.

Related Errors

• the stack has N pending operations — an interrupted update that left resources in an unknown state; a related but distinct recovery covered in its own guide.
• [409] Conflict from Pulumi Cloud — the server-side form of this same lock conflict.
• error: could not lock stack on a self-managed backend — a backend permissions problem rather than a held lock.
• snapshot integrity failure — checkpoint corruption that can follow a hard-killed update.

Frequently Asked Questions

Is it safe to run pulumi cancel? Only after you have confirmed no operation is actually running; cancel merely removes the lock, but doing so while a real update proceeds can corrupt your state.

Does pulumi cancel roll back my resources? No — it does not touch cloud resources or state; it only releases the lock so a new operation can start. Run pulumi refresh afterwards to reconcile drift.

Why did the lock get stuck in the first place? A previous operation was killed or lost connectivity before it could release the lock, leaving a stale record no live process owns.

How do I stop two CI jobs from colliding? Put deploys for a stack in a single CI concurrency group so they queue instead of running at once. For prompts that help you triage a locked or interrupted stack safely, see the Pulumi prompt library.

Where can I find more recovery guides? See the full Pulumi guides for lock, pending-operation, and state-recovery scenarios.