local
Kind: Enhanced
The local backend stores state on the local filesystem, locks thatstate using system APIs, and performs operations locally.
Example Configuration
terraform { backend "local" { path= "relative/path/to/terraform.tfstate" }}Data Source Configuration
data "terraform_remote_state" "foo" { backend= "local" config= { path= "${path.module}/../../terraform.tfstate" }}Configuration variables
The following configuration options are supported:
path- (Optional) The path to thetfstatefile. This defaults to"terraform.tfstate" relative to the root module by default.workspace_dir- (Optional) The path to non-default workspaces.
Command Line Arguments
This section describes legacy features that we've preserved for backwardcompatibility but that we no longer recommend. See below for more details.
For configurations that include abackend "local" block or that default tothe local backend by not specifying a backend at all, most commands that eitherread or write state snapshots from the backend accept the followingadditional arguments:
-state=FILENAME- overrides the state filename whenreading the priorstate snapshot.-state-out=FILENAME- overrides the state filename whenwriting new statesnapshots.If you use
-statewithout also using-state-outthen Terraform willuse the-statefilename for both-stateand-state-out, which meansTerraform will overwrite the input file if it creates a new state snapshot.-backup=FILENAME- overrides the default filename that the local backendwould normally choose dynamically to create backup files when it writes newstate.If you use
-statewithout also using-backupthen Terraform will usethe-statefilename as a filename prefix for generating a backup filename.You can use-backup=-(that is, set the filename to just the ASCIIdash character) to disable the creation of backup files altogether.
These three options are preserved for backward-compatibility with earlierworkflows that predated the introduction of built-in remote state, whereusers would write wrapper scripts that fetch prior state before runningTerraform and then save the new state after Terraform exits, in which casethe three arguments would typically all be paths within a temporarydirectory used just for one operation.
Because these old workflows predate the introduction of the possibility ofmultiple workspaces, setting themoverrides Terraform's usual behavior of selecting a different state filenamebased on the selected workspace. If you use all three of these options thenthe selected workspace has no effect on which filenames Terraform will selectfor state files, and so you'll need to select different filenames yourself ifyou wish to keep workspace state files distinct from one another.
These three options have no effect for configurations that have a differentbackend type selected.
We do not recommend using these options in new systems, even if you are runningTerraform in automation. Instead,select a different backend which supports remote state and configure itwithin your root module, which ensures that everyone working on yourconfiguration will automatically retrieve and store state in the correct sharedlocation without any special command line options.