Repository navigation
Add terraform force-lock #39428
Description
Terraform Version
Terraform v1.16.6Use Cases
During infrastructure maintenance events such as combining root modules and migrating state buckets, the ability to lock to state file via Terraform directly to prevent unexpected modification.
Attempted Solutions
While we do not have terraform force-lock, currently this can be done using the aws s3 cp to manually put a lock file into the terraform state bucket. This has several limitations as to where it requires a different scheme for dynamodb locks, etc.
Proposal
Create a terraform force-lock to lock a root module that provides the opposite functionality of terraform force-unlock. This makes maintenance more durable if other locking mechanisms are used in addition to s3 lock files. This also keeps the terraform state workflow in terraform instead of arbitrary aws s3 commands. This is the same as the fact that you could just delete the lock file with aws s3 rm $lockfile, but we prefer to manage terraform lock files through terraform.
Activity
crw commentedon Oct 21, 2026
Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!
jbardin commentedon Oct 21, 2026
See also #17203 #18407 #23433 #28710 and #30277 for more references
crw commentedon Oct 21, 2026
Would this be a duplicate of #28710?
rickeyski commentedon Oct 22, 2026
No, that feature request is for an expansion of
force-unlockto have broader visibility into locks. My request could be incorporated into that feature, but we have to be careful oflockbeing overloaded. I read that as a feature to manage Locks(capitalizing here to differentiate the noun vs the verb) viaMy proposal is to add
lockcommands which create Lock files, egforce-lock(lock here is lowercased because it is the verb). If we incorporated into a broader suite of Lock management per the PR above, it would beThe original proposal here is for
And this would trigger the state locking mechanism that plan's and apply's use without the overhead of starting a plan and ungracefully killing it to leave an orphan lock.
The larger lift to add dedicated Lock management subcommand to state does not apply to me because I have no interest in managing lock files. I simply want to be able to create lock files in the same manner which we can destroy them. We already have automation that prunes all orphan lock files every 2 minutes and are able to use the existing
-lock-timeout=120sto unblock plan and apply. However , if a state Lock management subcommand works for more people, I will be happy in whatever format theforce-lockcommand comes to fruition.Edson-Edwin commentedon Oct 22, 2026
jbardin commentedon Oct 22, 2026
Issue #17203 would be the most precise duplicate. That was rejected since the original backend implementation was intentionally designed to not handle this workflow, only providing guarantees about safety, not lock durability. It's possible this could be reconsidered in light of the pluggable state storage developments that have been happening, if the new protocol can describe the necessary lock constraints.