🚨 Pulumi Error: 'the stack is currently locked by 1 lock(s)' — Cause, Fix, and Troubleshooting Guide

Overview

error: the stack is currently locked by 1 lock(s) means Pulumi found a lock file in the state backend for the stack you are trying to operate on. Pulumi takes a lock at the start of any mutating operation (up, destroy, refresh, import) so that two processes cannot mutate the same stack state at once. If the message appears, Pulumi believes another operation is still holding that lock.

The full message names the backend path and, usually, who took the lock and when:

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`.
  s3://my-pulumi-state/.pulumi/locks/organization/myproject/dev/9d6e...json: created by james@ci-runner-7 (pid 4211) at 2026-07-14T10:42:07Z

Sometimes the lock is legitimate — a colleague or a CI job really is running pulumi up right now. But very often the lock is abandoned: a previous process was killed (Ctrl-C, a CI timeout, a crashed runner, a dropped SSH session) before it could release the lock. In that case the lock file is stale and safe to remove.

Symptoms

• pulumi up, pulumi destroy, pulumi refresh, or pulumi preview aborts immediately with the stack is currently locked by 1 lock(s).
• The error names a lock file path under .pulumi/locks/ in your backend (S3, Azure Blob, GCS, local ~/.pulumi, or Pulumi Cloud).
• No pulumi process is actually running on any machine (check your team and CI).
• A CI job that was cancelled or timed out immediately before this run.

Common Root Causes

1. A previous operation was interrupted before releasing the lock

The most common cause. Someone pressed Ctrl-C, a laptop went to sleep, or a CI pipeline hit its wall-clock timeout while pulumi up was mid-flight. Pulumi never got to delete its lock file, so the lock is now orphaned.

2. A concurrent operation really is in progress

Another engineer or a scheduled pipeline is genuinely running an update against the same stack at the same time. This is exactly what the lock is protecting against.

created by alice@laptop (pid 8123) at 2026-07-14T10:41:55Z

3. Two CI jobs targeting the same stack

Overlapping pipeline runs (for example a push and a merge landing seconds apart) both try to update prod and race for the lock. One wins, the other reports the stack as locked.

4. A crashed runner or killed container

A CI runner that was terminated (SIGKILL, spot-instance reclaim, OOM kill) leaves the lock file behind with no process to release it.

How to Diagnose

First confirm which stack you are on and where its state lives:

pulumi stack ls
pulumi whoami -v

Read the error carefully — it tells you the PID, host, and timestamp of the lock holder. If the timestamp is minutes or hours old and no one is running Pulumi, it is almost certainly stale.

Check whether a process is genuinely running. On the machine named in the lock:

ps aux | grep -i pulumi

Ask your team and inspect CI: is there a live pulumi up/destroy job right now? For self-managed backends you can also list the lock objects directly, e.g. on an S3 backend:

aws s3 ls s3://my-pulumi-state/.pulumi/locks/organization/myproject/dev/

Fixes

Preferred — if no operation is running, cancel the stuck lock. pulumi cancel releases the lock for the currently selected stack. It does not roll anything back; it only removes the lock file.

pulumi stack select dev
pulumi cancel

Then re-run your original command. Pulumi will re-read state and continue:

pulumi up

If an operation really is in progress — wait. Do not cancel a live update. Removing the lock while another pulumi up is writing state can lead to two processes mutating the same checkpoint and corrupting it. Wait for the other run to finish, then retry.

Cancel a specific stack without selecting it. Use --stack to target the locked stack explicitly, which is handy in scripts and CI:

pulumi cancel --stack myorg/myproject/dev --yes

Last resort — delete the lock object directly. If pulumi cancel cannot reach the backend but you can, delete the exact lock file named in the error. Only do this when you are certain no process is running:

aws s3 rm s3://my-pulumi-state/.pulumi/locks/organization/myproject/dev/9d6e...json

What to Watch Out For

• Never cancel a lock that a live process holds. Confirm via ps, your team, and CI before running pulumi cancel.
• pulumi cancel operates on the currently selected stack — double-check with pulumi stack ls (the active stack is marked with *) or pass --stack explicitly so you do not cancel the wrong environment.
• After cancelling, run pulumi refresh if the interrupted operation may have partly changed cloud resources, so state matches reality before the next up.
• In CI, serialize deployments per stack (concurrency groups / deployment queues) so two jobs never race for the same lock.
• Set sensible CI timeouts and add a cleanup step that runs pulumi cancel --yes on failure, so a killed job does not block the next run.
• Watch for a related but different error, conflict: another update is in progress, which is Pulumi Cloud’s server-side lock rather than a backend lock file.

Related Guides

• Pulumi Error: ‘conflict: another update is in progress’ — Troubleshooting Guide
• Pulumi Error: ‘resource(s) with pending operations’ — Troubleshooting Guide
• Pulumi Error: ‘no Pulumi.yaml project file found’ — Troubleshooting Guide