Push a New State Version Under Lock
A 6-step recipe with Terraform. We can help you get access.
Recipe · 6 steps
Push a New State Version Under Lock
with Terraform
Safely upload a new Terraform state version to a locked workspace.
- Lock the workspace before touching state. HCP Terraform rejects state uploads to an unlocked workspace, and the lock prevents a concurrent run from racing the migration.
- List the workspace's existing state versions, newest first, to learn the current serial so the replacement serial can be checked against it.
- Read the current state version for its hosted download URL, giving the caller a retrievable backup of the state about to be superseded.
- Upload the new state version to the locked workspace, supplying the serial, the MD5 checksum, and the base64-encoded state payload.
- Read the newly created state version back to confirm it was accepted and recorded with the expected serial before releasing the lock.
- Release the workspace lock now that the new state version is confirmed, so runs can resume against the migrated state.
What you'll need to have ready
- workspaceId: The workspace identifier whose state is being replaced.
- lockReason: The reason recorded on the workspace lock.
- stateSerial: The serial of the new state, which must exceed the current serial.
- stateMd5: The MD5 checksum of the raw state file being uploaded.
- stateBase64: The base64-encoded contents of the Terraform state file.
For your developer
Arazzo workflow terraform:migrate-state-version, 6 operations: LockWorkspace → ListStateVersions → GetStateVersion → CreateStateVersion → GetStateVersion → UnlockWorkspace. Specs on APIs.io.