Tailpipe puts log analysis in a terminal with DuckDB behind it

A local query loop instead of a pipeline to a vendor

Tailpipe opens with a line of SQL, `select * from logs;`, and that is the whole pitch. It is described as the lightweight, developer-friendly way to query logs, one that collects logs from cloud, container and application sources and lets you analyze the data instantly with the power of SQL, right from your terminal. The design decision is that everything stays local. It runs locally, powered by DuckDB's in-memory analytics and Parquet's optimized storage, and the project description says it can analyze millions of events in seconds, right from your terminal. For a security engineer who already writes SQL that is a familiar surface, and for one who has been fighting a query language invented for a SaaS product it is not. The topics list names aws, azure, gcp, duckdb, parquet, forensics, incident-response, log-analysis, detections, mitre-attack, siem and devops, which is a fair map of who it is for.

Plugins are how data gets in, and the config is HCL

The ingestion model is plugin based. You install a plugin for your service from the Tailpipe Hub, and the documented examples are AWS, Azure and GCP. The configuration lives in files under `~/.tailpipe/config/` with a `.tpc` extension, and it is written in HCL, the same configuration language Terraform uses. A file declares a connection and a partition, and the partition names the source it reads from.

connection "aws" "logging_account" {
  profile = "my-logging-account"
}

partition "aws_cloudtrail_log" "my_logs" {
  source "aws_s3_bucket" {
    connection = connection.aws.logging_account
    bucket     = "aws-cloudtrail-logs-bucket"
  }
}

The three configurable pieces the documentation calls out are the connection credentials, the table partition, and the data source, with separate pages for each. The `connection` block is where a profile or credential goes, the `partition` block is the table you will query, and the `source` block says where the bytes come from. That separation is what makes the same table name work across accounts and buckets, and it is also the thing you will edit most, so it is worth knowing that the config is declarative HCL rather than a YAML file the tool invented.

Install, install a plugin, then collect and query

The getting started path is four steps and it is worth following in order, because the plugin has to exist before a config file for it makes sense. On macOS the install is a Homebrew tap.

# MacOS
brew install turbot/tap/tailpipe

On Linux or Windows through WSL it is a shell installer.

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

Then the plugin, and then the collection.

tailpipe plugin install aws

tailpipe collect aws_cloudtrail_log

`tailpipe collect` is the step that downloads, enriches and saves logs from your source. After that, `tailpipe query` puts you in an interactive query mode, and the same SQL works as a one-off query. The example the documentation gives groups CloudTrail events by source and name.

select
  event_source,
  event_name,
  count(*) as event_count
from
  aws_cloudtrail_log
where
  not read_only
group by
  event_source,
  event_name
order by
  event_count desc;

Because the data is in Parquet and DuckDB is querying it, the tables are ordinary SQL tables, which is the point of the whole design. The `not read_only` filter is a column of the CloudTrail table, so filtering on it is a pushdown into the storage layer rather than a string match on rows you already loaded.

Prebuilt detections come from Powerpipe, not from Tailpipe itself

The detection layer is a separate product. Pre-built dashboards and detections for the AWS plugin are available as Powerpipe mods, and the AWS CloudTrail Logs Detections mod is described as scanning CloudTrail logs for anomalies such as an S3 bucket being made public or a change in VPC network infrastructure. The docs call the ecosystem of prebuilt intelligence MITRE ATT&CK-aligned queries, prebuilt detections, benchmarks and dashboards, all open source and community-driven, and the badges at the top of the README point at counters for plugins and mods, so both are growing. The architectural point is that Tailpipe is the storage and query layer and Powerpipe is the dashboard and control layer above it. That split has a practical consequence for adoption: if you want the detections, you are also taking on Powerpipe, and if you only want the query loop, you can stay with Tailpipe and write your own SQL. The docs mention the It is just SQL page, which suggests the maintainers consider the SQL surface the primary interface and the dashboards a convenience on top.

Building from source and the Go dependency shape

Contributing to the core binary is three commands, a clone, a make, and a version check.

git clone https://github.com/turbot/tailpipe

cd tailpipe
make

The `go.mod` describes the shape of the project, and it is a Go 1.26.1 module with a set of Turbot-owned dependencies that are pulled in as versioned modules rather than as local paths, including `pipe-fittings/v2`, the `tailpipe-plugin-sdk` and `tailpipe-plugin-core`. The replace block also shows that the same three can be swapped for local checkouts with a commented-out path, which is the arrangement a fork or a monorepo layout would use. The other dependencies say what the tool is. `hashicorp/hcl/v2` is the configuration language, `marcboeker/go-duckdb/v2` is the embedded analytics engine, `hashicorp/go-plugin` is the plugin mechanism, `charmbracelet/bubbletea` is the terminal interface, `c-bata/go-prompt` is the interactive query prompt, and `spf13/cobra` with `viper` handle the CLI. The Makefile builds with a version string derived from the branch name and a timestamp, and there are goreleaser targets for release dry runs and an acceptance build that run in a cross-compilation container with `CGO_ENABLED=1`, which is what you would expect from a project that embeds a C++ analytics engine.

AGPL source, commercial distribution, and the CLA

The licensing has two halves and both are stated plainly. The repository is published under the AGPL 3.0 licence, and the README says the project is a product produced from this open source software, exclusively by Turbot HQ, Inc, and is distributed under their commercial terms. Others are allowed to make their own distribution of the software but cannot use the Turbot trademarks, cloud services and similar, and the README points at an Open Source FAQ for the detail. That is a common shape for a commercial product with an open core, and it means the code you read is not the same package most people install. The contribution terms are also specific: contributors must sign the Turbot Contributor License Agreement as part of their first pull request, and there is a code of conduct in the shared organisation repository. The default branch is `develop` rather than `main`, which tells you something about how the release line is cut. The last push to the repository was on 2026-09-25, and the listed releases are v0.7.4 in May 2026, v0.7.3 in April 2026 and v0.7.2 in December 2025, so the gap between the last tag and the last commit is where the current work is.

Editorial conclusion

Adopt Tailpipe if you want to run log analysis locally with SQL and DuckDB instead of shipping logs to a hosted SIEM, and you are comfortable writing detection logic. Skip it if you need a multi-tenant managed service, since the project states it is distributed under Turbot's commercial terms, or if you need a stable release cadence, since the last push was on 2026-09-25 and the listed releases stop at v0.7.4 in May 2026. Before you commit, check which plugins and Powerpipe mods cover your services, and confirm the data directory and partition configuration fit how you want logs laid out on disk.

Frequently asked questions

Official sources

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