There are a few reasons not to store your .tfstate files in Git:
- You are likely to forget to commit and push your changes after running
terraform apply, so your teammates will have out-of-date.tfstatefiles. Also, without any locking on these state files, if two team members run Terraform at the same time on the same.tfstatefiles, you may overwrite each other’s changes. You can solve both problems by both a) storing.tfstatefiles in an S3 bucket using Terraform remote state, which will push/pull the.tfstatefiles automatically every time you runterraform applyand b) using a tool like terragrunt to provide locking for your.tfstatefiles. - The
.tfstatefiles may contain secrets. For example, if you use the aws_db_instance resource, you have to specify a database password, and Terraform will store that, in plaintext, in the.tfstatefile. This is a bad practice on Terraform’s behalf to begin with and storing unencrypted secrets in version control only makes it worse. At least if you store.tfstatefiles in S3, you can enable encryption at rest (SSL provides encryption while in motion) and configure IAM policies to limit who has access. It’s very far from ideal and we’ll have to see if the see open issue discussing this problem about it ever gets fixed.
For more info, check out How to manage Terraform state and Terraform: Up & Running, both of which I wrote.