# Error: could not create stack: the stack is currently locked by 1 lock(s)

## TL;DR
A stale lock from a dead process is blocking the stack. If no Pulumi run is actually active, delete the lock file at the path in the error (an S3 object on S3 backends) and retry.

## The error

```
error: could not create stack: the stack is currently locked by 1 lock(s). Either wait for the other process(es) to end or manually delete the lock file(s).
```

## Fix it

1. Check whether a run is genuinely active: look for running `pulumi` processes, CI jobs, or operator Stack objects reconciling.
   - Success check: nothing is actually running, so the lock is stale.
2. Read the lock file path from the error (e.g. `s3://[bucket]/.pulumi/locks/[stack]/[id].json`) and check its `created by` line and timestamp. A lock from a dead pod or a hours-old timestamp is safe to remove.
   - Success check: the lock owner no longer exists.
3. Delete the lock: for S3 backends, delete the object (`aws s3 rm s3://[bucket]/.pulumi/locks/[stack]/[id].json`); for local backends, remove the file under `.pulumi/locks`.
   - Success check: the lock path no longer exists.
4. Re-run the stack operation.
   - Success check: the stack creates/selects without the lock error.

## When to use this
You hit this when creating or selecting a stack and the error names a lock file whose owner (pod, process, timestamp) is clearly gone.

## When NOT to use this
Do not delete locks while a run is actually in progress. Two writers on one stack corrupt state. Verify first, delete second.

## Compatibility
Pulumi CLI 3.x, S3 and local backends, commonly seen via the Pulumi Kubernetes operator.

## Variants
- `error: the stack is currently locked by [n] lock(s)` with more than one stale lock (delete each)
- The same error on `pulumi up` rather than stack creation, when a previous update was killed

## Root cause
Pulumi takes a lock per stack operation. If the process dies (pod eviction, OOM, Ctrl-C at the wrong moment) without releasing it, the lock file survives and blocks every later operation until removed.

## Edge cases
- The operator can recreate the situation if its workspace pod keeps crashing. Fix the crash loop too, or the lock returns.
- `pulumi cancel` releases the lock of a *running* update gracefully. Prefer it when something is actually running.