Terrastore · live
Terraform state, authenticated by GitHub.
A drop-in remote backend for Terraform. OIDC in CI, terraform login from your laptop, full state history with a browser you'll actually use. No API keys in workflows, no second permission system, no SaaS platform to onboard.
terraform {
cloud {
hostname = "terrastore.runsheet.dev"
organization = "<your-github-org>"
workspaces {
name = "<repo>.<workspace>"
}
}
}Why Terrastore
No secrets, no second permission system.
Authorization is whatever GitHub already says you can do — checked live, on every request.
No long-lived secrets
Every CI run authenticates with a GitHub OIDC token minted for that exact job. Local runs use terraform login — revocable bearer tokens, no stored API keys.
Permission follows GitHub
Org admins manage enrolment; repo permissions gate state access live, on every request. Admin or write on the repo is full access; read is read-only.
TFE-compatible API
A drop-in replacement for the cloud {} block. Workspaces, locking, versioning — the pieces Terraform already expects.
A state browser, not just storage
Click into any version, browse resources by type, expand attribute trees, reveal sensitive values when you actually need them.
Local and CI on the same auth
Refactor with terraform state mv locally; deploy with OIDC from CI. Same backend, same state, no juggling credentials.
Full version history
Every save is kept. Roll back to any prior serial. Different environments and repos stay completely separate.
How it works · in CI
Two paths into the same backend.
Whether you're running GitHub Actions or sitting at your laptop, it is the same cloud block.
- 01
The job mints an OIDC token
Set
id-token: writein permissions; GitHub hands the job a one-time token pinned to its repo and environment. - 02
Terrastore checks the token
Validates it against GitHub's keys and derives the workspace from the claims. The job can only ever touch its own state.
- 03
terraform apply runs as normal
Same runner, same Terraform binary. The stage is the workflow's
environment:— wire it to a GitHub Environment for required-reviewer protection.
How it works · locally
- 01
terraform login
The browser opens, you sign in with GitHub, click Authorize. A bearer is saved to
~/.terraform.d/credentials.tfrc.json. - 02
Terrastore asks GitHub
Every request asks: is this user allowed on this repo right now? Admin or write gets full access; read gets read-only. Cached briefly to keep things fast.
- 03
Plan, apply, refactor
State moves, imports, the works. Revoke the token any time from the console's token page.
In the console
The human-shaped parts of state.
Onboarding
Install the Runsheet GitHub App on an org, pick which repos to enrol. GitHub admins only.
State browser
Resources grouped by module, attributes per instance, sensitive values masked by default with reveal on click.
Locks and force-unlock
See who is holding a lock and clear stale ones. The backend sees the change on the next request.
CLI tokens
Every token issued to your laptops, when it last ran, revoke instantly. No stored secrets to leak.
How it compares
Between a bucket and a platform.
Terrastore sits between a raw S3 backend and a full platform like Terraform Cloud or Spacelift.
| S3 + DynamoDB | Terraform Cloud / Spacelift | Terrastore | |
|---|---|---|---|
| CI auth | AWS creds in CI | API token in CI | Ephemeral GitHub OIDC |
| Local auth | AWS creds on laptop | User API token | terraform login (GitHub OAuth) |
| Access control | IAM you maintain | SaaS RBAC you maintain | GitHub repo permissions, live |
| State browser UI | No | Yes | Yes |
| Remote execution | No | Yes (vendor runners) | No — runs on your runner |
| Pricing | AWS bill | Per resource / per run | $1 per active repo per month |
Ready to try it?
Sign in with GitHub, install the App, enrol a repo, drop the cloud block in. Then terraform apply.