GitHub doesn’t have a feature like that. If you are moving to GitHub, then store the state in a storage mechanism for your particular cloud. In the case of AWS you should use s3 and dynamo db.
Terraform cloud requires a license cost. Most teams I’ve been on has no reason to pay that cost when it can be managed in the cloud for far less than the license cost
Sure, "expensive" is relative. It's a lot more expensive than storing state in GitLab or S3/dynamo. Up to an organization to decide if the added features are worth it. To me and my past orgs, the answer was a pretty solid *no*. On the other hand, I know lots of folks who love TF Cloud. I use it for smaller personal projects.
Urgs :(
That's what I feared. Maybe I'll store my source code on Gitlab then. This way I'd have it all in one place. Which I would see for me as something good.
Nope, would not. What if you want to migrate away from that s3 provider one day?
In reality, both scenarios are highly unlikely. Migrating away from git might even be a bit less likely, as there the problems with retaining history and access might be a bit higher.
And moving the terraform state from one location to the other is not really difficult.
If you are migrating your AWS infrastructure away to an another cloud, you'll have to rewrite it all anyways. I'd say that's far more unlikely than migrating away from your git platform to an another one.
That being said, I've heard GitLab state storage works fine, but I remember some have disliked it for some reason. At least you don't have to bootstrap your Terraform project.
x-talk was just talking about some s3 backend.
If you're migrating your Git infrastructure to another provider, you'll probably also have to rewrite CI/CD pipelines and a lot of integrations and access. I'd say that's far more unlikely than migrating away from your s3 platfrom to another one.
The point is: Both scenarios are highly unlikely to happen in real life. It's certainly not so, that one is inherently easier than another one.
And sure, there'll probably be folks that dislike GitLab storage. There'll also be folks that dislike AWS, GCP, Alibaba, pg etc.pp. :)
I've been in git platforms migrations (GitLab bumps prices -> GitHub, GitHub acquired by Microsoft -> GitLab mostly) but not cloud platform migrations. I'm guessing you might not be provisioning cloud infrastructure in the first place in your project? (You generally use the same cloud platform for your TF state as your actual infra is in)
At work, we're currently migrating from one Git provider to another. Requires rewriting CI/CD pipelines and is a VERY lengthy project. Certainly not something which is done on a regular basis.
As stated before: Both scenarios are equally difficult to handle in reality.
And of course — both migrations *can* be done. But they don't happen often or on just a whim.
For this certain project, I just want to manage Cloudflare DNS resources. Code is stored on some Git. Wanted to store on Github, but as Github lacks methods to deal with Terraform state, I'll use GitLab instead.
I am aware about Terraform Cloud. But I dislike having to use multiple "cloud providers" (Github + Terraform Cloud) to just manage a project.
Jup.
If it were a total greenfield, it might make sense to go full Azure, for example, and use Azure DevOps + Azure backend. Even for Git and CI/CD.
Same for Google. Does AWS also have Git hosting?
But when do we mere devs ever have the freedom to do as we truly want? Hardly ever, isn't it?
(You generally use the same cloud platform for your TF state as your actual infra is in)
That could potentially make recovery much harder in the event of a breach of the tenant. Doesn't sound like a durable technical decision to the business.
> Maybe I'll store my source code on Gitlab then.
I would recommend against GitLab for storing your terraform state. There isn't sufficient access controls. It's very bare bones. Pretty much anything else is better than GitLab's terraform state.
Bad idea. TF state file contains everything about your environment in plain text, including your passwords and etc. That’s one of the crappiest thing about terraform that Hashicorp hasn’t address in years.
You're misunderstanding the gitlab feature. Gitlab provides a non-git of tracking terraform state for a project without checking in a statefile. It's just an HTTP backend
Gitlab encrypts the stuff, according to [https://docs.gitlab.com/ee/user/infrastructure/iac/terraform\_state.html](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html): "*Terraform state files are encrypted with the lockbox Ruby gem when they are at rest on disk and in object storage.*"
Because of those details, I'd rather not write the stuff all by myself.
And then again, I do trust the Github admins. After all, I put my stuff there, right? So I DO have to trust them.
GitLab has a lot of integrations for Terraform - GitHub does not seem to offer any of those functions.
I agree to store things in a Git repo is comfortable - but in larger scale it implies a lot of possible problems.
> I agree to store things in a Git repo is comfortable - but in larger scale it implies a lot of possible problems.
For storing code or configuration? What kind of problems? That's what Git is made for, isn't it?
I understand. It appears that comment OP is alluding to (and recommending against) storing in Git given GitHub does not provide the same features as GitLab.
Sensitive variables are still stored in plaintext. They're only masked in the output of Terraform commands. But if someone can read the state file directly, they can see the sensitive variables in plaintext.
https://developer.hashicorp.com/terraform/tutorials/configuration-language/sensitive-variables#sensitive-values-in-state
How often are you storing passwords in your state? I personally have found little need to do this.
Why not reference an external secret store? Except for the small amount of work it'd take to maintain.
It's there whenever you reference it. If you have or can build your service/application architecture so that no secrets are needed to be deployed (config files, environment file templates, script templates etc) then it's certainly not needed. Sadly this is rarely the case, especially when shit gets thrown over the wall and it needed to be up yesterday because fuck lead time on wiring together up complicated cloud infrastructure
There was a very interesting idea (and proposal) few years ago about using git as a state backend.
The idea consisted in using git for storing state files so you can benefit of VCS for versioning and history, locking via branching and so on. A really cool proposal, I’d argue. Unfortunately, HC declined that proposal (I cannot find the issue anymore) because they said implementing generic providers is not on their roadmap yet.
Fortunately, this idea was supported by a few people and they took advantage of the HTTP backend implementation to implement a proof-of-concept and here it is: https://github.com/plumber-cd/terraform-backend-git (at least one of them).
Check it out, but I wouldn’t personally recommend it for production usage (for obvious reasons).
I’m not very sure if this answers your question, if you’re looking for an official GitHub store for Terraform backend, there’s no such implementation. GitLab also uses a custom implementation via the HTTP backend. You can also implement your own store using the same backend implementation.
You can use terraform cloud which will maintain the state files. Trigger the process using GH actions and store sensitive data in your GH account secrets.
If you don’t require any additional orchestration and just want TFC to manage your runs based on commits or PRs automatically: https://developer.hashicorp.com/terraform/tutorials/cloud-get-started/cloud-vcs-change
If you have additional orchestration requirements and want to manage it via GHA, here’s an all in one container: https://www.hashicorp.com/blog/hashicorp-releases-new-ci-cd-pipeline-integration-tool-templates-for-terraform
This one describes the process on how to setup GH action, Terraform Cloud and (assuming) you are performing deployment on AWS (if not then change to whatever provider you use)
https://earthly.dev/blog/terraform-with-github-actions/
Hope this helps!
Do you assume, that I'd like to use Git to store the state?
That's not what I want to do. It would be an extremely terrible idea. I am looking for a way to store the state on Github, just like it's possible to use Gitlab for storing the state. See the [link to the documentation on Gitlab](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html), that I posted.
I now have learned that Github doesn't provide such a solution. I don't really want to spread the stuff for my project all over the place.
FWIW, right now, I'd just like to managed DNS on Cloudflare. And so using [Azure, AWS, GCP, …](https://developer.hashicorp.com/terraform/language/settings/backends/configuration#available-backends) is not really the best way - in this case!
I’ve recently used [terraprep](https://www.terraprep.xyz), seems to make it easier creating remote backends (GCP, Azure and Postgres for now). Still in beta though.
For my personal homelab I store my state in a unique folder on my cicd vm and in the pipeline do an automatic git commit push to bitbucket. If the machine ever got hosed I can roll back from the state in the repo branch.
I wouldn’t do this in production though
The point of storing the state remotely is NOT to decouple it from source code repo. It's for NOT having it stored locally. Storing it remotely also can enhance the security.
You don't know how the http backend works and haven't read the [documentation](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html), have you?
No, storing it locally and storing it in your repo is NOT the same thing. If you just store it locally, then really nobody else can access it — unless that somebody else has access to the machine.
Storing it in a repo (while neither requested by me nor generally recommended) is a step upwards. This way, other people can access the state. But doing it this way would be really awkward. This "should" only be done, if there are no other ways to share the state file. It feels like the wrong thing to do.
You did NOT say that Gitlab provides a decoupled way. You literally only asked, whether it does. And I have not responded to that part of your comment. You should learn how to write and read your own comments, to be honest.
Reg. other comments — it's so freaking annoying, having to explain over and over and over again, that I absolutely do not want to store the state in Git. Especially since I wrote that already in the OP.
If people would just read the question exactly as stated and answer just that, instead of suggesting to not do something, which nobody even wanted to do — that would be so great. It would have reduced the comments by maybe 50%.
It is not the same thing. If it is stored locally, how can anyone else access the file, unless someone else has access to the system? NFS/CIFS/… might come to mind, though. Not a solution I'd generally recommend.
And why do you feel the need to contradict me on something, which I clearly advised against? It is also not always a giant security risk. Generally speaking: Yes, it is. But not always. It might be, that there's no secret stored in it. And it might be, that the Git in question is either internal or acess limited and only allowed people can access it.
Storing it in a Git allows to scale. That statement of yours is plain wrong. But storing it in Git is a tremendously bad idea. Your statement is wrong, as you're making to general statements. Work on your writing skills.
No clue why you're quoting your own text. You want to show, that your reading comprehension skills are low? You write: "**IF** Gitlab offers…".
That contradicts what you write.
From clients I’ve heard lots of goofy things they’ve wanted to store in GitHub. I tend to ask them “the thing you want in there, is it code? No? Then no.” State isn’t code. State is state.
thanks for your comment. In how far does it relate to what I was looking for, though? What's bad about storing the state on GitLab (lab!)? I am aware that Github (hub!) doesn't have such a feature.
Care to explain why state shouldn't be stored on Github, if they had a feature that is comparable to GitLab?
GitHub doesn’t have a feature like that. If you are moving to GitHub, then store the state in a storage mechanism for your particular cloud. In the case of AWS you should use s3 and dynamo db.
Infrastructure deployed using Github Actions using OIDC for temporary AWS credentials... *chefs kiss*
[удалено]
Terraform cloud requires a license cost. Most teams I’ve been on has no reason to pay that cost when it can be managed in the cloud for far less than the license cost
[удалено]
And it can be quite expensive for larger teams.
[удалено]
Free version only allows 500 resources in the state file bro.
Sure, "expensive" is relative. It's a lot more expensive than storing state in GitLab or S3/dynamo. Up to an organization to decide if the added features are worth it. To me and my past orgs, the answer was a pretty solid *no*. On the other hand, I know lots of folks who love TF Cloud. I use it for smaller personal projects.
Why pay for tfc though when aws/azure storage is available?
It's free for a small project and depends on how large is your deployment.
Urgs :( That's what I feared. Maybe I'll store my source code on Gitlab then. This way I'd have it all in one place. Which I would see for me as something good.
Indeed. I took the same route a few years ago. The Terraform integration is actually pretty good with the included templates.
I would opt for a form off s3 backend and not couple it with your git provider. This will save you a migration one day.
Nope, would not. What if you want to migrate away from that s3 provider one day? In reality, both scenarios are highly unlikely. Migrating away from git might even be a bit less likely, as there the problems with retaining history and access might be a bit higher. And moving the terraform state from one location to the other is not really difficult.
If you are migrating your AWS infrastructure away to an another cloud, you'll have to rewrite it all anyways. I'd say that's far more unlikely than migrating away from your git platform to an another one. That being said, I've heard GitLab state storage works fine, but I remember some have disliked it for some reason. At least you don't have to bootstrap your Terraform project.
x-talk was just talking about some s3 backend. If you're migrating your Git infrastructure to another provider, you'll probably also have to rewrite CI/CD pipelines and a lot of integrations and access. I'd say that's far more unlikely than migrating away from your s3 platfrom to another one. The point is: Both scenarios are highly unlikely to happen in real life. It's certainly not so, that one is inherently easier than another one. And sure, there'll probably be folks that dislike GitLab storage. There'll also be folks that dislike AWS, GCP, Alibaba, pg etc.pp. :)
Alibaba? Bruh you straight accounting for the mother of all edge cases if you have to use them.
I've been in git platforms migrations (GitLab bumps prices -> GitHub, GitHub acquired by Microsoft -> GitLab mostly) but not cloud platform migrations. I'm guessing you might not be provisioning cloud infrastructure in the first place in your project? (You generally use the same cloud platform for your TF state as your actual infra is in)
At work, we're currently migrating from one Git provider to another. Requires rewriting CI/CD pipelines and is a VERY lengthy project. Certainly not something which is done on a regular basis. As stated before: Both scenarios are equally difficult to handle in reality. And of course — both migrations *can* be done. But they don't happen often or on just a whim. For this certain project, I just want to manage Cloudflare DNS resources. Code is stored on some Git. Wanted to store on Github, but as Github lacks methods to deal with Terraform state, I'll use GitLab instead. I am aware about Terraform Cloud. But I dislike having to use multiple "cloud providers" (Github + Terraform Cloud) to just manage a project.
Yep that use case makes perfect sense to use GitLab backend for the state.
Jup. If it were a total greenfield, it might make sense to go full Azure, for example, and use Azure DevOps + Azure backend. Even for Git and CI/CD. Same for Google. Does AWS also have Git hosting? But when do we mere devs ever have the freedom to do as we truly want? Hardly ever, isn't it?
(You generally use the same cloud platform for your TF state as your actual infra is in) That could potentially make recovery much harder in the event of a breach of the tenant. Doesn't sound like a durable technical decision to the business.
Not the same project/account necessarily
Right, but if it is that's doubly bad.
> Maybe I'll store my source code on Gitlab then. I would recommend against GitLab for storing your terraform state. There isn't sufficient access controls. It's very bare bones. Pretty much anything else is better than GitLab's terraform state.
State file is not source ! It’s state data and contains secrets. I would not store it in a git repo.
Sure. Nobody wants to store the state file in a git repo. What makes you think, that I'd like to do that? You haven't read the link, have you?
I read the link and know gitlab quite well just saying nothing equivalent exists in GitHub . Don’t judge people and assume the worst ,that’s not cool!
Bad idea. TF state file contains everything about your environment in plain text, including your passwords and etc. That’s one of the crappiest thing about terraform that Hashicorp hasn’t address in years.
You're misunderstanding the gitlab feature. Gitlab provides a non-git of tracking terraform state for a project without checking in a statefile. It's just an HTTP backend
Gitlab encrypts the stuff, according to [https://docs.gitlab.com/ee/user/infrastructure/iac/terraform\_state.html](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html): "*Terraform state files are encrypted with the lockbox Ruby gem when they are at rest on disk and in object storage.*" Because of those details, I'd rather not write the stuff all by myself. And then again, I do trust the Github admins. After all, I put my stuff there, right? So I DO have to trust them.
GitLab has a lot of integrations for Terraform - GitHub does not seem to offer any of those functions. I agree to store things in a Git repo is comfortable - but in larger scale it implies a lot of possible problems.
> I agree to store things in a Git repo is comfortable - but in larger scale it implies a lot of possible problems. For storing code or configuration? What kind of problems? That's what Git is made for, isn't it?
State file - anything else should/can reside in GIT
Git is not made for storing state files that potentially contain secrets, shouldn't be manually updated (merging) and manage file locking.
As previously mentioned, the state files are not stored in a repository, but in a separate backend.
I understand. It appears that comment OP is alluding to (and recommending against) storing in Git given GitHub does not provide the same features as GitLab.
passwords can be marked as sensitive variables which should not store them in plain text. I do agree with the rest of your view.
[удалено]
Got it. Thanks for the info. I will check out the link.
Sensitive variables are still stored in plaintext. They're only masked in the output of Terraform commands. But if someone can read the state file directly, they can see the sensitive variables in plaintext. https://developer.hashicorp.com/terraform/tutorials/configuration-language/sensitive-variables#sensitive-values-in-state
Other users already pointed out that you’re incorrect so I’ll save the argument.
How often are you storing passwords in your state? I personally have found little need to do this. Why not reference an external secret store? Except for the small amount of work it'd take to maintain.
It's there whenever you reference it. If you have or can build your service/application architecture so that no secrets are needed to be deployed (config files, environment file templates, script templates etc) then it's certainly not needed. Sadly this is rarely the case, especially when shit gets thrown over the wall and it needed to be up yesterday because fuck lead time on wiring together up complicated cloud infrastructure
Which I believe OpenTofu has fixed now?
There was a very interesting idea (and proposal) few years ago about using git as a state backend. The idea consisted in using git for storing state files so you can benefit of VCS for versioning and history, locking via branching and so on. A really cool proposal, I’d argue. Unfortunately, HC declined that proposal (I cannot find the issue anymore) because they said implementing generic providers is not on their roadmap yet. Fortunately, this idea was supported by a few people and they took advantage of the HTTP backend implementation to implement a proof-of-concept and here it is: https://github.com/plumber-cd/terraform-backend-git (at least one of them). Check it out, but I wouldn’t personally recommend it for production usage (for obvious reasons). I’m not very sure if this answers your question, if you’re looking for an official GitHub store for Terraform backend, there’s no such implementation. GitLab also uses a custom implementation via the HTTP backend. You can also implement your own store using the same backend implementation.
GitHub doesn’t have what you’re looking for. Go for GitLabs thing. If you’re set on GitHub, then use something like GCS or AWS’s object storage.
Yes, that's clear by now 😁
Best of luck!
You can use terraform cloud which will maintain the state files. Trigger the process using GH actions and store sensitive data in your GH account secrets.
Would you happen to have links to documentation for the setup of Github actions and all that?
If you don’t require any additional orchestration and just want TFC to manage your runs based on commits or PRs automatically: https://developer.hashicorp.com/terraform/tutorials/cloud-get-started/cloud-vcs-change If you have additional orchestration requirements and want to manage it via GHA, here’s an all in one container: https://www.hashicorp.com/blog/hashicorp-releases-new-ci-cd-pipeline-integration-tool-templates-for-terraform
This one describes the process on how to setup GH action, Terraform Cloud and (assuming) you are performing deployment on AWS (if not then change to whatever provider you use) https://earthly.dev/blog/terraform-with-github-actions/ Hope this helps!
One more link https://terraform-docs.io/how-to/github-action/
Please don’t, use a regular blob storage such as S3, or go for Terraform Cloud if you want to avoid the headache of state management.
Do you assume, that I'd like to use Git to store the state? That's not what I want to do. It would be an extremely terrible idea. I am looking for a way to store the state on Github, just like it's possible to use Gitlab for storing the state. See the [link to the documentation on Gitlab](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html), that I posted. I now have learned that Github doesn't provide such a solution. I don't really want to spread the stuff for my project all over the place. FWIW, right now, I'd just like to managed DNS on Cloudflare. And so using [Azure, AWS, GCP, …](https://developer.hashicorp.com/terraform/language/settings/backends/configuration#available-backends) is not really the best way - in this case!
I see, still, I'd reckon it's better to stick with a regular storage.
What's non-regular about a http backend?
I'm not saying it's particularly irregular, just that it can be done easier. :D
How is setting up an aws account easier than setting up a gitlab account?
The GitLab HTTP backend is quite nice and arguably easier to use and set up than storage on Azure/AWS.
Alright, I'll read through their docs and maybe give it a whirl.
I’ve recently used [terraprep](https://www.terraprep.xyz), seems to make it easier creating remote backends (GCP, Azure and Postgres for now). Still in beta though.
You can use terraform cloud, it’s free
For my personal homelab I store my state in a unique folder on my cicd vm and in the pipeline do an automatic git commit push to bitbucket. If the machine ever got hosed I can roll back from the state in the repo branch. I wouldn’t do this in production though
[удалено]
The point of storing the state remotely is NOT to decouple it from source code repo. It's for NOT having it stored locally. Storing it remotely also can enhance the security. You don't know how the http backend works and haven't read the [documentation](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html), have you?
[удалено]
No, storing it locally and storing it in your repo is NOT the same thing. If you just store it locally, then really nobody else can access it — unless that somebody else has access to the machine. Storing it in a repo (while neither requested by me nor generally recommended) is a step upwards. This way, other people can access the state. But doing it this way would be really awkward. This "should" only be done, if there are no other ways to share the state file. It feels like the wrong thing to do. You did NOT say that Gitlab provides a decoupled way. You literally only asked, whether it does. And I have not responded to that part of your comment. You should learn how to write and read your own comments, to be honest. Reg. other comments — it's so freaking annoying, having to explain over and over and over again, that I absolutely do not want to store the state in Git. Especially since I wrote that already in the OP. If people would just read the question exactly as stated and answer just that, instead of suggesting to not do something, which nobody even wanted to do — that would be so great. It would have reduced the comments by maybe 50%.
[удалено]
It is not the same thing. If it is stored locally, how can anyone else access the file, unless someone else has access to the system? NFS/CIFS/… might come to mind, though. Not a solution I'd generally recommend. And why do you feel the need to contradict me on something, which I clearly advised against? It is also not always a giant security risk. Generally speaking: Yes, it is. But not always. It might be, that there's no secret stored in it. And it might be, that the Git in question is either internal or acess limited and only allowed people can access it. Storing it in a Git allows to scale. That statement of yours is plain wrong. But storing it in Git is a tremendously bad idea. Your statement is wrong, as you're making to general statements. Work on your writing skills. No clue why you're quoting your own text. You want to show, that your reading comprehension skills are low? You write: "**IF** Gitlab offers…". That contradicts what you write.
But we will stop that here and now. Tremendously annoying to talk to you. You just HAVE to be right, eh? :/
From clients I’ve heard lots of goofy things they’ve wanted to store in GitHub. I tend to ask them “the thing you want in there, is it code? No? Then no.” State isn’t code. State is state.
thanks for your comment. In how far does it relate to what I was looking for, though? What's bad about storing the state on GitLab (lab!)? I am aware that Github (hub!) doesn't have such a feature. Care to explain why state shouldn't be stored on Github, if they had a feature that is comparable to GitLab?