> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/infrastructure-as-code-management/platform/workspaces/lock-workspace.md).
# Lock a workspace
Lock a workspace to block apply and destroy operations during change freezes, maintenance, or state surgery. Optionally block plan and drift detection with a project setting.
Harness IaCM lets you manually lock a workspace to block apply and destroy operations. By default, plan and drift detection can still run on a locked workspace. To also block plan and drift detection, enable the **Block Plan While Locked** project setting.
A workspace lock does not modify the workspace state file. It blocks apply and destroy from starting while the lock remains in place. Locking does not cancel any operation that is already running. Any user with the **Workspace Lock/Unlock** permission can lock or unlock a workspace.
***
## Before you begin
* You must have the **Workspace Lock/Unlock** permission on the workspace. Go to [Workspace Permissions](/infrastructure-as-code-management/platform/workspaces/workspace-rbac.md) to configure access.
* To block plan and drift detection on locked workspaces, enable the **Block Plan While Locked** project setting in your project. Go to [Block plan and drift detection](#block-plan-and-drift-detection) below.
***
## Lock a workspace
To lock a workspace:
1. Select your workspace from the workspace list.
2. Select the three-dot menu next to the **Check for Drift** button.
3. Select **Lock**.
4. Enter a reason for locking the workspace. The reason is stored with the lock and visible to other users.
5. Select **Lock workspace**.
The workspace list displays a lock icon next to the workspace status to indicate that the workspace is locked.
***
## Unlock a workspace
To unlock a workspace:
1. Select your locked workspace from the workspace list.
2. Select the three-dot menu next to the **Check for Drift** button.
3. Select **Unlock**.
4. Review the warning and select **Unlock Workspace** to confirm.
{% hint style="warning" %}
If a pipeline execution is still running against the workspace when you unlock it, the unlock may cause inconsistent state. Verify that no pipeline runs are active before unlocking.
{% endhint %}
***
## Block plan and drift detection
By default, a workspace lock blocks apply and destroy operations but allows plan and drift detection. Enable the **Block Plan While Locked** project setting to also block plan and drift detection.
This setting applies to all Terraform, OpenTofu, and Terragrunt workspaces in the project.
To enable block plan while locked:
1. Go to **Project Settings**.
2. Select **IaCM Settings**.
3. Under **IaCM Defaults**, select **Provisioning configuration**.
4. Enable **Block plan and drift while a workspace is locked**.
When this setting is on and a plan or drift detection step runs against a locked workspace, the step fails with the following error:
```
plan and drift are blocked while the workspace is locked.
[TIP]: This project blocks plan and drift while a workspace is locked.
Wait for the in-progress apply or destroy to finish, or ask an admin to unlock the workspace, then re-run.
```
The step result is marked as **SUCCESS (FAILURE IGNORED)** if your pipeline stage is configured to continue on failure, or it fails the pipeline stage if not.
***
## Workspace locking and state locking
Workspace locking is a manual control that you apply to prevent pipeline operations from running against a workspace. It is distinct from state locking, which is automatic and per-run.
State locking happens automatically when a plan or apply operation starts. It prevents two pipeline runs from modifying the same state file concurrently. The lock releases when the operation completes or fails. A pipeline that is aborted mid-run may leave a stale automatic state lock that requires manual removal.
Workspace locking persists until you explicitly unlock it. It is for scenarios where you need to protect a workspace across multiple pipeline runs, not just within a single run.
Go to [State management](/infrastructure-as-code-management/use-iacm/iac-provisioners/opentofu/state-management.md#state-locking) to understand how automatic state locking works and when to unlock manually.
***
## Troubleshooting
Plan or drift detection fails with 'workspace is locked'
The **Block Plan While Locked** setting is enabled and the workspace is locked. Verify that no apply or destroy operation is actively running against the workspace, then ask a user with the **Workspace Lock/Unlock** permission to unlock the workspace. Re-run the pipeline after the workspace is unlocked.
A stale automatic state lock remains after a pipeline is aborted
An aborted pipeline may leave a stale automatic state lock on the workspace. This is different from a manual workspace lock. To remove a stale state lock, follow the unlock procedure in [Unlock a workspace](#unlock-a-workspace). Verify no other pipeline runs are active before unlocking.
***
## Next steps
* Go to [Workspace Permissions](/infrastructure-as-code-management/platform/workspaces/workspace-rbac.md) to configure the **Workspace Lock/Unlock** RBAC permission for your team.
* Go to [State management](/infrastructure-as-code-management/use-iacm/iac-provisioners/opentofu/state-management.md#state-locking) to understand how automatic per-run state locking works and when to unlock manually.
* Go to [Provision a workspace](/infrastructure-as-code-management/platform/workspaces/provision-workspace.md) to run plan, apply, and destroy operations after unlocking.
## FAQs
Does locking a workspace prevent all pipeline runs?
Locking prevents apply and destroy operations from starting. Plan and drift detection still run unless the project setting **Block Plan While Locked** is enabled. A lock does not change the state file and does not stop a run that has already started. You need the **Workspace Lock/Unlock** permission to lock or unlock a workspace.
{% @harness-feedback/feedback %}