Today we're promoting all three of Turbot's open source components — Steampipe, Powerpipe, and Flowpipe — to v1.0.0. It's a major milestone on a journey that began with the launch of Steampipe v0.1.0 on January 21, 2021, along with an initial suite of 13 plugins featured on the then-new Steampipe Hub.

The first version of Steampipe's most popular plugin, [AWS](https://hub.steampipe.io), provided 68 tables, already a formidable collection that has since grown to nearly [500](https://hub.steampipe.io/plugins/turbot/aws). In the [inaugural blog post](https://steampipe.io/blog/introducing-steampipe) we wrote: > Steampipe, a new open source project from Turbot, enables cloud pros (e.g. software developers, operations engineers and security teams) to query their favorite cloud services with SQL. It has quickly become one of our favorite tools in-house and we hope it finds a way into your toolbox as well. Nearly four years later, that hope has become a reality. Here are a few top-line Steampipe stats:

6,876	GitHub stars
145	plugins
125	news and reviews

The core query capability provided by Steampipe plugins was soon augmented with a suite of [mods](https://hub.steampipe.io/mods) that focused, initially, on compliance checks for AWS, Azure, GCP, and a few others. These mods wrapped Steampipe queries in HCL-defined controls and benchmarks tailored to the [Center for Internet Security](https://www.cisecurity.org/cis-benchmarks) recommendations. Today we offer compliance mods for Audit Manager Control Tower, AWS Foundational Security Best Practices, CIS, FedRAMP, FFIEC, GDPR, HIPAA, NIST, PCI, SOC 2, and many more, along with mods for asset inventory/insights, shift-left scanning, and cost management.

17	compliance
21	asset inventory and insights
6	shift-left scanning
6	cost control

These continue to evolve rapidly. [AWS Compliance](https://hub.powerpipe.io/), for example, now provides 1,229 controls and 30 dashboards, and adds support for security and compliance benchmarks on a [regular basis](https://github.com/turbot/steampipe-mod-aws-compliance/blob/main/CHANGELOG.md). Today all these mods join the v1.0.0 release party. ## From benchmarks to dashboards From the beginning we've standardized on two declarative languages: SQL to acquire data from clouds, HCL to report and visualize. That core pattern has carried through the suite of open source components, while evolving along the way. Initially, for example, the benchmarks we provided (and that you could [compose or create](https://steampipe.io/blog/release-0-11-0) yourself) used HCL to declare and combine controls. Then, with [Dashboards as Code](https://steampipe.io/blog/dashboards-as-code), we added new HCL syntax for [tables](https://powerpipe.io/docs/powerpipe-hcl/table), [chart](https://powerpipe.io/docs/powerpipe-hcl/chart), [infocards](https://powerpipe.io/docs/powerpipe-hcl/card), [inputs](https://powerpipe.io/docs/powerpipe-hcl/input), [relationship graphs](https://powerpipe.io/docs/powerpipe-hcl/graph), and more. What had been an engine for running benchmarks could now also power dashboards, all in the as-code, GitHub-friendly style of modern DevOps. The arrival of [relationship graphs](https://steampipe.io/blog/release-0-18-0) showcased the value of this approach. Use SQL to query AWS for sets of resources related to, for example, a VPC. Then use HCL to visualize its full context. ![relationship graph](/images/blog/2024-10-open-source-v1/relgraph.png) ## Database-agnostic plugins Originally, Steampipe plugins ran in a captive instance of Postgres equipped with a plugin manager and [foreign data wrapper](https://github.com/turbot/steampipe-postgres-fdw) extension. People often asked: "Can we also run those plugins in our own databases?" We made it so, with "zero-ETL" distributions of plugins for [your own instance of Postgres](https://steampipe.io/blog/2023-12-postgres-extensions), or for [SQLite](https://steampipe.io/blog/2023-12-sqlite-extensions). While we were at it, we also made them available as [standalone exporters](https://steampipe.io/blog/2023-12-steampipe-export). Now a bigger picture started to come into focus. The Steampipe ecosystem, as it grew and evolved, was becoming a suite of components that worked well together in their original contexts, but could be recombined to serve other purposes in other contexts. ## Powerpipe emerges from Steampipe

Next, we realized that the benchmarks-and-dashboards subsystem included with Steampipe ought to be [unbundled](https://steampipe.io/blog/steampipe-unbundled) from the core query engine. These were logically two different components that worked well together, but needn't be joined at the hip. Once decoupled from Steampipe, for example, the benchmarks-and-dashboards subsystem could become database-agnostic just as plugins had. Thus was born [Powerpipe](https://powerpipe.io), a standalone tool that runs all your [benchmarks and dashboards](https://powerpipe.io/blog/migrating-from-steampipe) but can also connect to [any Postgres](https://powerpipe.io/docs/powerpipe-hcl/query#postgres), or [SQLite](https://powerpipe.io/docs/powerpipe-hcl/query#sqlite), or [MySQL](https://powerpipe.io/docs/powerpipe-hcl/query#mysql), or [DuckDB](https://powerpipe.io/docs/powerpipe-hcl/query#duckdb). Now you could build dashboards-as-code to visualize data in your own instance of Postgres, or even data living in [Parquet files](https://thenewstack.io/llm-assisted-translation-from-postgres-to-sqlite-and-duckdb/) using DuckDB. Decoupled from Steampipe, Powerpipe could still serve its original purpose while also enabling wider ambitions. ## Flowpipe delivers HCL-powered workflows for DevOps

All this visibility into resources and their configuration prompted users to ask: "How can we act on everything we can now see?" To build DevOps workflows that create, update, and delete you have to orchestrate scripting, CLI commands, Lambda functions, containers, and human approvals across multiple providers and identity frameworks. Bash and Python have served us well, but there had to be a better way. Enter [Flowpipe](https://flowpipe.io), Turbot's third major open source component, which debuted in [December 2023](https://flowpipe.io/blog/introducing-flowpipe). It's "like an HCL-powered alternative to Step Functions", said [Aidan Steele](https://x.com/__steele/status/1735411461399453996). Noting Flowpipe's DAG-powered implicit parallelisation, he added: "I wish SFN had that!" Like Steampipe and Powerpipe, Flowpipe is a self-contained binary that you can easily deploy locally, or in any CI/CD enviroment. Like its siblings, it's supported by a [hub](https://hub.flowpipe.io) where you can find prebuilt workflows for common DevOps chores, supported by libraries that you can use to build your own workflows, and samples that capture common patterns.

35	library mods
41	sample mods

And yes, these mods also join today's v1.0.0 release party. ## Semantic versioning We've held onto v0.x for a long time, allowing the tools to evolve and mature. Now that we see their shapes clearly we'll continue to move them forward, and we'll do that with regular releases that follow semantic versioning. And with a solid pattern in place, we're in a great position to grow the family of components. ## Many components, one community In Turbot's [Slack community](https://turbot.com/community/join), nearly 7,000 users and contributors gather to discuss Steampipe, Powerpipe, and Flowpipe, along with the growing suites of mods they enable. You can use these core components individually to query cloud resources, report on them, and act on them. And they work even better together as when, for example, a Steampipe query feeds a Powerpipe dashboard or a Flowpipe pipeline. Flipping the v1.0.0 switch is always an emotional moment. We're just getting started, but it was time to recognize the maturity of this ecosystem and celebrate with everyone who has traveled with us on this journey. Thanks, and stay tuned!

v1.0 for Steampipe, Powerpipe, Flowpipe, 116 plugins, and 44 mods