Powerpipe turns cloud configuration data into dashboards and compliance benchmarks you keep in git

A dashboarding tool for cloud resources, not a generic chart library

The problem Powerpipe addresses is visibility into cloud configuration and the security posture that follows from it. The README frames it as dashboards for DevOps: visualise any data source and run compliance benchmarks and controls that enable decision making and ongoing compliance monitoring. High-level dashboards give an overview and are meant to highlight misconfigurations and hotspots, and results can be filtered, pivoted and snapshotted.

The third pillar is relationship diagrams, described as the only dashboarding tool designed from the ground up to visualise DevOps data, so you can explore your cloud, understand relationships and drill into details. That claim is the project's own, but it does mark a difference in emphasis: the target is infrastructure topology rather than business metrics.

The users are DevOps and DevSecOps teams already running on AWS, Azure, GCP, Kubernetes, Terraform and GitHub, and the topics attached to the repository list cloud security posturing, compliance and infrastructure as code. Teams that only need a chart of their application metrics are not the audience.

Dashboards are code, which is the point

The phrase the README uses for this is code, not clicks. Dashboards are described as version-controlled, composable, shareable and easy to edit, designed for the way you work. In practice that means a dashboard is an HCL definition rather than a saved state inside a web application, and the documentation links an HCL reference page alongside pages for viewing dashboards, running benchmarks, CLI commands, configuration files and building mods.

This has a real consequence for review processes. A change to what your security dashboard shows can be diffed, reviewed and reverted like any other source change, and the same dashboard file can be promoted between environments. It also means there is no drag and drop editor mentioned anywhere in the documentation, so anyone expecting a console experience will have to learn HCL.

Configuration is a separate documented topic with its own reference page, so connection settings and behaviour live in files rather than in a saved session.

5,000+ controls sourced from CIS, NIST, PCI, HIPAA and FedRamp

The benchmark side is where the compliance value sits. The README states that 5,000+ open source controls are offered, credited to CIS, NIST, PCI, HIPAA, FedRamp and more, and they can be run instantly on your machine or as part of your deployment pipeline. The controls are distributed through the mod hub rather than being written into the binary, which is what keeps the core small and lets you run only the frameworks you care about.

Mods are described as sets of pre-built dashboards that visualise your resources together with benchmarks that check cloud resources for compliance. Ready to use mods exist for AWS, Azure, GCP, GitHub, Kubernetes, Terraform and M365, and the hub filters mods by objectives that include compliance, cost management, shift-left scanning, and asset inventory and insights.

That shift-left angle deserves attention. A mod in the infrastructure as code category exists to check configuration before it is applied, which is a different point in the lifecycle from scanning a running cloud account.

Database agnostic queries over Postgres, SQLite, DuckDB and MySQL

Powerpipe does not own your data. The README says Powerpipe is database agnostic, and that samples are provided for dashboards that use other data sources via Postgres, SQLite, DuckDB and MySQL. Many mods are written for Steampipe and its plugin ecosystem, which is the path for pulling live data out of cloud accounts, but the query layer works against ordinary databases too.

The dependency list backs this up. The Go module requires the DuckDB, SQLite, MySQL and Postgres drivers, alongside the Steampipe plugin SDK, which is how a single dashboard definition can query a local file database or a shared Postgres instance without changing the dashboard itself.

There is a practical consequence. If your team already lands resource inventory into a database through another pipeline, Powerpipe can visualise it without granting a new credential to a cloud account. If you have no data source at all, you need one before any dashboard renders anything.

Installing on macOS, Linux or Windows through WSL2

The README points to the downloads page and gives two shell routes. On macOS the Homebrew tap is the documented path.

# MacOS
brew install turbot/tap/powerpipe

On Linux, or on Windows using WSL2, the documented command is an install script piped to a shell.

# Linux or Windows (WSL2)
sudo /bin/sh -c "$(curl -fsSL https://powerpipe.io/install/powerpipe.sh)"

Note the use of sudo and the direct pipe from curl into a shell: the script runs with elevated privileges, so you may want to read the script before running it if that is not your usual practice on a workstation.

Once installed, the next step the README gives is to set up and visualize your first dashboard, with the documentation at powerpipe.io/docs as the entry point. The command reference page lists the CLI commands, and configuration is covered on its own page, so credentials and data source wiring are configured through those two areas rather than through flags shown in the README.

Building the binary from source with make

The repository documents how to build the core binary, and the steps assume you clone two repositories: Powerpipe itself and the pipe-fittings library.

git clone [email protected]:turbot/powerpipe
git clone [email protected]:turbot/pipe-fittings

The build itself is a make invocation from the Powerpipe directory.

cd powerpipe
make

The binary lands in /usr/local/bin unless you specify an alternate OUTPUT_DIR, and the check is a version and help pair.

powerpipe --version

powerpipe --help

The Makefile shows what is underneath: the build target runs go build with a version stamp derived from the git branch and a timestamp, and a separate target builds the dashboard assets inside the ui directory. Release packaging runs through goreleaser inside a Docker container, and an acceptance test generator lives under tests/acceptance. The module file declares go 1.26.7 and the module path github.com/turbot/powerpipe.

AGPL 3.0, the CLA and a trademark boundary

The repository is published under the AGPL 3.0 licence, and the README states that contributors must sign Turbot's Contributor License Agreement as part of their first pull request. That is an unusual combination for a community project and it is worth reading before you contribute.

The licence has a direct effect on how you can use the tool. AGPL 3.0 is a copyleft licence with a network use clause, so a modified version offered to users over a network carries source availability obligations. The README also says that Powerpipe is a product produced from this open source software exclusively by Turbot HQ, Inc, that it is distributed under Turbot's commercial terms, and that others may make their own distribution but cannot use the Turbot trademarks or cloud services. This is a description of what the project states, not legal advice, and organisations with a formal licence review should read the LICENSE file and the linked Open Source FAQ.

For collaboration, the README points at a code of conduct, a Slack channel and a contributor agreement. For teams that want the same stack hosted, Turbot Pipes is the paid option, with Steampipe for data access, Powerpipe for query visualisation and Flowpipe for workflow automation.

Steampipe for data, Powerpipe for visualisation, Flowpipe for action

The three way split is the clearest way to understand where Powerpipe sits. Steampipe is the SQL style tool for querying cloud data from the command line. Powerpipe is the layer that renders those query results as dashboards and benchmarks. Flowpipe is the workflow automation piece. The README describes a Pipes workspace as the place where all three are used together, in the cloud.

The difference in approach between Steampipe and Powerpipe is therefore the difference in output. Steampipe answers questions at a terminal, one query at a time. Powerpipe turns a saved set of queries into a repeatable dashboard with controls and snapshots attached, which is what makes it usable in a pipeline or as a standing report rather than a one-off investigation.

Compare that with a cloud posture management service that reports findings through a vendor console. The console gives you findings without asking you to host anything; Powerpipe gives you findings you own as code, at the cost of running the binary and providing the data source yourself. Teams that value the second property can put it in version control next to their infrastructure code.

Editorial conclusion

Powerpipe is worth adopting when a team wants cloud posture and compliance findings to live in version controlled HCL next to the code it describes, and when it already has a data source such as Steampipe or one of the supported SQL databases. It is the wrong tool for teams that need a turnkey SaaS with no open source core to self host, for organisations unwilling to accept AGPL 3.0 obligations, or for anyone who wants a point and click console rather than a configuration file. Before committing, run powerpipe --version after installing from the downloads page, then check that a mod exists for your cloud provider and that its benchmarks match the frameworks your auditors ask about.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. turbot/powerpipe on GitHub