Pipedash: one screen for pipelines across seven CI providers

Why one screen and not seven dashboards

Most teams end up using multiple CI platforms. Open source projects run on GitHub Actions, internal services use GitLab CI or Buildkite, Kubernetes workloads use Tekton, and there is always that one Jenkins server handling legacy work. Checking everything means opening a bunch of tabs and hitting refresh. Pipedash exists to remove that, pulling pipeline data from the providers and showing it in a single view, with pipelines organised by repository and workflow. The supported list is GitHub Actions, GitLab CI, Bitbucket Pipelines, Buildkite, Jenkins, Tekton CD and ArgoCD, and the plugin system is the stated answer to what comes next, so the provider list is a starting set rather than a fixed boundary. The mechanism is polling rather than webhooks: Pipedash refreshes in the background on an interval you set per provider, and a status change shows up as soon as the next poll returns. Everything runs locally on your machine, and the project states plainly that it only connects to your CI providers, with no analytics, telemetry or third party services.

Triggering with parameters, re-running and cancelling

A dashboard that only shows status is a read only view, and Pipedash goes past that. You can trigger workflows with parameters, and the parameters are not typed in by hand: Pipedash loads them from the provider, meaning workflow inputs for GitHub Actions, pipeline variables for GitLab CI, and build parameters for Jenkins and Buildkite, then renders them as a form. You can also re-run a previous execution with the same parameters, which is the feature that turns a failed release build into a two click retry rather than a manual reconstruction, and you can cancel builds that are running. A detail that matters for larger organisations is that Pipedash supports multiple instances of the same provider, for example two different GitHub organisations, so the abstraction is provider plus instance rather than provider alone. Setup follows the same logic: after you add a provider, Pipedash validates the credentials, fetches the available repositories, and lets you pick which ones to monitor.

Token storage: the system keyring, or AES-256-GCM

The credential model is the part of a CI aggregator that deserves scrutiny, and Pipedash offers three options. The system keyring is the default on the desktop app, where the operating system encrypts the tokens, through the macOS Keychain, Windows Credential Manager or the Linux Secret Service, and no password of yours is involved. The second option is an encrypted SQLite database, where Pipedash encrypts tokens with AES-256-GCM using Argon2id derived keys, and it works on every platform including a headless server. The third is encrypted PostgreSQL, the same AES-256-GCM scheme with the encrypted values stored in PostgreSQL, which is the one to pick for a team deployment on the PostgreSQL backend. The distinction is between trusting the operating system's key store and carrying your own key, and the Argon2id derivation is what makes a password-derived key acceptable rather than naive. Pipeline data itself is stored separately from the credentials, in SQLite or PostgreSQL, and both backends work on desktop and on the web.

The web API is open unless you set a vault password

Here is the sentence to read twice. When PIPEDASH_VAULT_PASSWORD is set, Pipedash requires authentication for API requests, and the vault password does double duty: it encrypts your provider tokens and secures API access, with every request needing the header Authorization: Bearer <vault_password>. If the environment variable is not set, the API remains open, which the project describes as suitable for local use or behind a VPN. That is a reasonable default for a tool that runs on your own machine, and an obvious hazard for a team deployment exposed on a network, so setting the variable is the first thing to do when you move from the desktop app to the server. The setup wizard makes the choice explicit, since it offers the storage backend and the token storage method as separate decisions, and it also handles data migration, so you can switch backends at any point and take the providers, credentials and pipeline history with you or start fresh.

Three ways to run it, including a Docker deployment

The desktop app is the main route, a native Tauri application for macOS, Windows and Linux, downloaded from the releases page. There is also an iOS app on the App Store, which is the odd and interesting one, since a phone is a reasonable place to check whether a release pipeline is stuck. The third route is Docker, and the repository ships ready-to-use setups in the examples directory, one for SQLite and one for PostgreSQL. Each has a compose file you edit to add your tokens, and the tasks are run through mise:

# SQLite backend (simplest)
mise run examples:sqlite:up
mise run examples:sqlite:down

# PostgreSQL backend
mise run examples:postgres:up
mise run examples:postgres:down

Two details make the container route workable. The API server serves the frontend directly, because it is embedded in the binary, so there is no separate web server to deploy, and your data persists in a Docker volume rather than inside the container layer.

The crate layout mirrors the provider list

The Rust workspace is arranged the way the feature set is, with one crate per provider alongside the shared pieces. The members are pipedash-core, which holds the business logic and is framework agnostic, pipedash-desktop for the Tauri application with the system keyring integration, and pipedash-web for the REST API server used in headless deployments, plus pipedash-plugin-api and one plugin crate for each supported provider: argocd, bitbucket, buildkite, github, gitlab, jenkins and tekton. The split is the reason the same code runs as a desktop app, as an API server or embedded in something else. On the front end the desktop package is a Vite and React project using TypeScript, with Mantine for the interface, TanStack Query for data fetching, Monaco for editing, and Zustand for state. The plugin API crate is what makes the provider list extensible, and the plugin crates are where the provider specific credentials and parameter shapes live.

One token and one scope list per provider

The setup section is short because the shape is consistent, and it is the best summary of what Pipedash needs from you. GitHub Actions wants a personal access token with the repo and workflow scopes, and it accepts a custom base URL for GitHub Enterprise. GitLab CI wants a personal access token with the api scope and works with GitLab.com and self hosted instances. Buildkite wants an API access token with read permissions and your organisation slug. Jenkins wants an API token, a username and the server URL. Tekton CD wants a Kubernetes config file path and a context, and Pipedash auto detects the namespaces that hold Tekton pipelines. ArgoCD wants a server URL and an auth token, supports filtering by Git organisations, and monitors sync status, health and deployment history. Bitbucket Pipelines wants an app password with repository and pipeline read permissions, for Bitbucket Cloud and self hosted. The scopes are the widest part of the setup, and they are where a careful administrator should push back, since Pipedash needs write access to trigger, re-run and cancel.

What version 0.1.1 tells you

The version number is the clearest signal about maturity. The workspace version and the desktop package version are both 0.1.1, the latest tagged release is v0.1.1 from 2025-12-31, and before it came v0.0.10 and v0.0.9, so the project has been iterating quickly through pre-1.0 versions. The last push was on 2026-08-31, inside the six month window, so the work is current even though the tags are not. Under semantic versioning a 0.x release carries no compatibility promise, and for an application that talks to seven external APIs and stores credentials, that is a real caveat. The licence is GPL-3.0, so if you intend to run the self hosted web deployment as part of a service you offer, that licence needs reading. The plugin system is the other thing to watch, since a provider that is not on the list depends on someone writing a plugin against an API that is still moving.

Editorial conclusion

Pipedash is worth a try for a team whose CI runs on more than one platform and whose engineers now keep a wall of browser tabs open to check it. The desktop app is the sensible starting point, because the system keyring removes token handling from the picture entirely. It is the wrong choice if you need a vendor with a support contract, if you are on version 0.1.1 and need a stability promise, or if your providers require credentials you cannot scope. Before you connect anything, read the token storage section, decide between the keyring and the encrypted database, and set PIPEDASH_VAULT_PASSWORD before exposing a web deployment to anything but localhost.

Frequently asked questions

Official sources

1. hcavarsan/pipedash on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases