# terraform-visual: turning a Terraform plan into a browsable report > This project takes the JSON output of terraform show and renders it as a report you can open in a browser, either by uploading the plan to a hosted app or by running a CLI locally. The plan stays the source of truth, and the tool only draws it. **hieven/terraform-visual** — Terraform Visual is an interactive way of visualizing your Terraform plan - Repository: https://github.com/hieven/terraform-visual - Website: https://hieven.github.io/terraform-visual - Stars: 674 · Forks: 64 - Language: TypeScript - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/hieven-terraform-visual ## The plan JSON is the only input The README describes Terraform Visual as a simple but powerful tool to help you understand your Terraform plan easily, and the repository description calls it an interactive way of visualizing your Terraform plan. The scope is deliberately narrow, and that is what makes it useful. The input is a plan in JSON format, which Terraform itself produces. The first step is always the same two commands, a plan written to a file and that file read back out as JSON: ```shell $ terraform plan -out=plan.out # Run plan and output as a file $ terraform show -json plan.out > plan.json # Read plan file and output it in JSON format ``` Nothing in that sequence is Terraform Visual's business, and that is the point. The tool never runs Terraform, never talks to a cloud provider and never needs credentials. It reads a file that already exists, which means it can be used on a plan generated in one place and reviewed in another, and it means there is no permission surface to audit beyond the plan file itself. The topics attached to the repository include terraform-graph and terraform-plans, which describes the intended shape of the output. What it does not do is decide anything. The tool draws the plan; the reading of what the plan means stays with the reviewer. ## Three ways to use it, with different data handling The README documents three ways to consume the tool, and the choice between them is really a choice about where the plan file goes. The first is the hosted web app at hieven.github.io/terraform-visual. The instruction is to generate the plan in JSON format, visit the site, and upload the Terraform JSON to the platform. The README frames this as being for people who want to quickly experience how Terraform Visual looks like. The second is the CLI, published to npm as `@terraform-visual/cli`, and the README is explicit about why it exists: for people who don't like to upload a Terraform plan to the public internet. Install it and then run the CLI against the JSON file, which produces a report on disk. The third is the Docker image, published on Docker Hub as `hieven/terraform-visual-cli`, and it is described as being on top of official Terraform plus the Terraform Visual CLI. The stated use is integrating it into an existing CI/CD pipeline, and the instruction is simply to replace the Terraform image in your pipeline with this one and get both command line tools. So the tool has a hosted mode, a local mode and a pipeline mode. That is unusual for a small visualisation utility, and it reflects that the audience includes both people trying the tool and teams wiring it into delivery. ## The CLI writes a static report you can open locally The CLI path is the one to look at if the plan cannot leave your machine. Installation is a global npm install: ```sh $ npm install -g @terraform-visual/cli ``` The plan is converted to JSON with the same two Terraform commands used in the hosted flow, and then the report is created with the CLI: ```sh $ terraform-visual --plan plan.json ``` The output is a directory, and the report is opened from the file system rather than from a server: ```sh $ open terraform-visual-report/index.html ``` The shape of the result is the important detail for a team. It is a generated directory named `terraform-visual-report` with an `index.html` in it, not a hosted link, which means it can be attached to a pull request comment, zipped and sent to a reviewer, or opened from a file share. The plan data never has to leave the environment that produced it. The README defers the details of the CLI to the npm package page for `@terraform-visual/cli`, so the flag set and the output format are documented there rather than in the repository. ## The Docker image exists to sit in a pipeline The Docker route is the least documented in the README and the most interesting for a delivery team. The image is on Docker Hub as `hieven/terraform-visual-cli`, and the README states that it is built on top of official Terraform plus the Terraform Visual CLI. That single fact is the design. A pipeline that currently runs Terraform in a container can swap that image for this one and keep the same Terraform commands while gaining the report generation, with no separate install step and no second container to orchestrate. The README describes it as being for people who like Terraform Visual and want to integrate it into an existing CI/CD pipeline, and points to the Docker Hub page for more details. The trade-off is that the image is a bundled pair of tools. If your pipeline pins a specific Terraform version, the Terraform inside this image is whatever the image ships, and the version is not stated in the README. That is the first thing to check before putting it in a pipeline that cares about Terraform version, and the Docker Hub tags are the place to look for it. ## The repository is a docs site plus a CLI package Based on the repository layout, this is two projects in one place. There is a `cli` directory for the npm package, a `gh-pages` directory for the hosted web app, a `docs` directory holding the demo material, and a tsconfig.json, with .eslintrc and .prettierrc for the TypeScript source. The primary language is TypeScript, and the web app is published on GitHub Pages at the address in the repository homepage. The hosting arrangement explains a detail of the usage. The web app lives on GitHub Pages, which is why the README calls the hosted path an upload to a public site, and why the CLI exists as a separate route for people who do not want to do that. Both are first-class in the documentation rather than one being a fallback for the other. The repository has no releases, and the npm package is the distribution channel for the CLI, so the version you get is the one npm serves. The topics list adds terraform-graph, which is the clearest hint about what the rendering is aiming at: a graph of the plan's resources and the changes between them, rather than a diff view. ## MIT licensed, actively pushed, with no tagged releases The repository is not archived and the last push was on 2026-10-16, so the project is being worked on. The repository has no GitHub releases, which for a project whose artefacts are a hosted app and an npm package is a reasonable arrangement, since the npm version is the meaningful one for anyone automating it. The licence is MIT, with the LICENSE file at the root. That is a permissive licence with a notice requirement, and for a tool that reads a plan file and writes a report, it imposes no obligations on the plan data itself. Any review of licensing here should be about the tool, not about the infrastructure descriptions inside your plan. The GitHub workflow directory is present for continuous integration, and the repository carries the usual .gitignore alongside the formatting configuration. There is no CONTRIBUTING file or code of conduct at the top level, and no changelog file, so the npm version history and the repository history are the two places to look for what changed and when. ## Conclusion terraform-visual fits a team that reviews infrastructure changes with people who do not read raw plan JSON, and that can get a plan file to a reviewer. It is the wrong choice if your plans contain sensitive values you cannot hand to a hosted page, unless you use the CLI locally, and the wrong choice if you want the tool to analyse the plan, since it visualises and leaves judgement to you. Verify first which of the three usage modes fits your data handling rules, that the CLI produces a report directory you can attach to a review, and that the version of the CLI on npm matches the branch you are reading. ## FAQ ### What does terraform-visual need to produce a report? A Terraform plan in JSON format, which you get by running terraform plan -out=plan.out and then terraform show -json plan.out > plan.json. The tool reads that file, it does not run Terraform itself. ### How do I use terraform-visual without uploading my plan anywhere? Install the CLI with npm install -g @terraform-visual/cli, then run terraform-visual --plan plan.json. It writes a terraform-visual-report directory with an index.html that you can open locally, which the README presents as the option for people who do not like uploading a plan to the public internet. ### Can terraform-visual be used in a CI/CD pipeline? Yes. A Docker image is published on Docker Hub as hieven/terraform-visual-cli, built on top of official Terraform plus the Terraform Visual CLI. The README says you can replace the Terraform image in your pipeline with this one to get both command line tools. ### What licence is terraform-visual released under? MIT, with the LICENSE file at the repository root. The project is written in TypeScript, and the CLI is published to npm as @terraform-visual/cli. ## Sources - [hieven/terraform-visual on GitHub](https://github.com/hieven/terraform-visual) - [Issues](https://github.com/hieven/terraform-visual/issues) - [License: MIT](https://github.com/hieven/terraform-visual/blob/master/LICENSE) - [Project website](https://hieven.github.io/terraform-visual) - [README](https://github.com/hieven/terraform-visual/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hieven-terraform-visual