Terraform: Should terraform.tfstate be committed into source control?

Created on 24 Apr 2017  ยท  15Comments  ยท  Source: hashicorp/terraform

As a best practice, is it recommended to commit terraform.tfstate into source control, or should it be excluded?

question

Most helpful comment

Just also be sure to add the following to .gitignore to prevent pushing sensitive Terraform information.

.terraform
*.tfstate.backup

All 15 comments

As a best practise, I think it is recommended to store terraform.tfstate in a Terraform backend as described here:
https://www.terraform.io/docs/backends/
The link also explains why.

@horsey thanks for the reply. Just migrated from local to gcs and it all worked flawlessly. Only bummer is losing locking.

I wonder if the gcs backend could implement locking via a simple file lock in the bucket.

Originally storing the state in version control, along with the config, was a common practice. When we introduced remote state storage some time ago we considered both to be valid approaches, but recommended remote state storage.

With the introduction of the "backend" concept in 0.9, along with the support for state locking, our position is now that remote backends are the only recommended mechanism, and state should not be placed into version control with the config. In future versions we will invest in making backends even more robust (including adding locking to other backends), and so we'd suggest that any teams currently using state in version control migrate to remote backends soon.

In the mean time, we would be happy to review PRs for adding locking support to the existing backends, assuming that the backend in question has some reasonable locking primitive available.

Since this is a question rather than an issue, I'm going to close this now.

I am new to terraform.

Where should we version terraform configuration file (.tf)? in the same repo as the related project source code or you create a separate repository?

Nothing stops from storing your terraform files in the same repo as your project, but terraform files are related to your infrastructure and not related to your application/project source code per se, hence making it logical to store it in a different repository altogether.

Just also be sure to add the following to .gitignore to prevent pushing sensitive Terraform information.

.terraform
*.tfstate.backup

Shout you add out.plan files as well to the .gitignore?

yes, because it can contain sensitive information

@apparentlymart What are the drawbacks of checking terraform.tfstate into source control? It seems to me that putting it the same place as the .tf files makes a lot of sense.

It appears that some provisioners leave sensitive data in terraform.tfstate, so that's certainly one reason.

exactly, terraform state can contain for example initial password of AWS RDS

There are a few different variant workflows out there, but the primary one we recommend is to get changes through PR and merged _before_ applying them, since that way the changes are forced into a particular order by the git history.

Having the state in version control would encourage the opposite ordering: applying first and _then_ pushing the change to VCS. That creates the risk of forked state as two people try to apply something at the same time or apply things in the "wrong" order.

As an analogy, think of terraform apply as being the _deployment_ of the change. For application code you will generally merge changes into version control and _then_ deploy them. The same workflow applies to Terraform, with the changes to state being just another side-effect of the deployment along with the changes to the real resources. Ideally in a production environment terraform apply is also automated in a similar way as app deployment so that it is happening in a central location where all collaborators can see it.

You can also use s3 as state remote backend https://www.terraform.io/docs/backends/types/s3.html

I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

Was this page helpful?
0 / 5 - 0 ratings