TFstate.dev: a Free Hosted Terraform HTTP Backend accessible using a GitHub Token

Terraform
1

Greetings! I’ve developed a new service called TFstate.dev!

TFstate.dev is a free-to-use hosted HTTP Backend for Terraform State Storage that is accessible using a GitHub Token.

The backend API is Open Source for transparency and confidence that your state files are securely hosted: https://github.com/tfstate/github-sls-rest-api

Here’s an example usage of it:

terraform {
  backend "http" {
    address        = "https://api.tfstate.dev/github/v1"
    lock_address   = "https://api.tfstate.dev/github/v1/lock"
    unlock_address = "https://api.tfstate.dev/github/v1/lock"
    lock_method    = "PUT"
    unlock_method  = "DELETE"
    username       = "{your-github-org}/{your-github-repo}"
  }
}

terraform init -backend-config="password={your-github-token}"
terraform plan
terraform apply

There’s no signup or registration, and with a GitHub token, you can immediately start using this as a Terraform Backend. State is secured and encrypted in Amazon S3 using KMS. State Locking is also natively supported.

Using it is as simple as generating a GitHub token, setting a few lines of config in Terraform, then enjoying the benefits of Shared and Secure state storage without first signing up for TF Cloud or creating S3 buckets, DDB tables and juggling Access Credentials just to get the same feature set.

I’d love to get everyone’s feedback, and if you’re currently using a different Terraform State backend, feel free to migrate to this service to store your state.

Let me know what you think!

Christian

2

To me, this sounds uncomfortably close to a large scale phishing scam to collect people’s GitHub tokens.

It might be entirely innocent, just poorly planned, but it’s a fact that this asks people to give over powerful credentials just to prove identity.

IMO, if you want to promote yourself to be successful service you really need to fix this ASAP.

Quoting from https://tfstate.dev :

At a minimum, the token needs repo:read access for the configured repository.

Except there’s a problem here - there’s no such access scope listed on GitHub “New Personal Access Token” page https://github.com/settings/tokens/new. The closest similar name, which less security-conscious users may end up picking, is repo, which gives read and write permissions to PRIVATE repositories.

There is a fairly well accepted standard protocol now (OAuth 2.0 as extended by OpenID Connect) for doing authentication via an existing web service identity. That would be the way to go for a service like this.

A different issue: Don’t fall into the trap of offering “free forever” storage. Define your permitted storage quota, and period after which inactive accounts will have their storage deleted, now, so users have their expectations calibrated correctly from the start.

3

Great feedback @maxb thank you!

Yeah intentions are innocent but I can see how it could be construed that way, and I partly blame GitHub for not having better PAT scopes, it frustrates me everyday! All I really need to know is “can Token X access Repo Y”, and certainly a GitHub App would fix that, and I’ll add it to my thoughts on how a GitHub App would fit into this picture, so again thanks for the feedback!

On a note of pricing, you are right! I also wanted to go against the flow with and not have a Freemium model and just give it away, something like State storage is so foundational and should be free and easy IMHO. I also use it exclusively with my personal projects and some of my professional projects, so I’m planning to maintain it for as long as terraform is “a thing”

I value your input, if you have any other things you’d like to discuss, you can hit me up on twitter! @cnuss