GUI for visualising your remote Terraform states in a Clouformation-esque way
Terraformation was built by a lover of the Terraform but who wanted after a small subset of the features offered by AWS Cloudformation - primarily the GUI. Hence the play on Terra(formation).
In order for Terraformation to work it needs read access to your S3 Terraform state bucket. Being a Terraform visualisation tool, we would of course recommend using Terraform for this - as we did for the demo version of this repository here
You can set specific access keys with TF_BUCKET_AWS_ACCESS_KEY_ID and TF_BUCKET_AWS_SECRET_ACCESS_KEY, otherwise Terraformation will simply use the default AWS configuration provided to the container.
ghcr.io/benjackwhite/terraformation:latest
Tagged commits on the main branch are pushed as Docker images to the github registry
This Docker image can be deployed to Kubernetes or otherwise as a simple stateless deployment.
To run locally see the docker-compose.yaml file as a starting point.
WARNING: This option is probably fine for demo's or deployments with little-to-no sensitive state. It is probably the easiest way to get started but gives you the fewest options for securing your web deployment. See their page on protecting-deployments for more information
- Self-deployable either as a Docker container or to Vercel as a Next.js website / API.
- List view of all existing Terraform states in your remote backend, including workspaces
- Searchable and easy to browse list of resources within a Terraform state as well as outputs and the raw JSON if desireable
- Server-side redaction of all sensitive values such as passwords, access keys
- Link from resource to Terraform docs as well as resources like AWS if determinable
- History View - With S3 versioning it would be possible to see a diff-like view of the deploys
- Support for other remote backends - Currently only S3 is supported
- Alternative visualisations - Integration with other 3rd party tools to generate graph-like views
- State Dependencies - It should be possible to determine which states use resources from other states by matching "resource" IDs with "data resource" IDs to build an inter-state depdency tree of sorts
- ╳ Complex login flows - if you need special auth I would expect this to be done in your Kubernetes Ingress or AWS ALB rules instead
- ╳ Destroy / update commands - Running Terraform apply / destroy requires access to your raw code / provider credentials which would make this a much more sensitive and complex project