Pipedash

Pipedash aggregates CI/CD pipeline status from GitHub Actions, GitLab CI, Jenkins, Tekton, Buildkite, ArgoCD, and Bitbucket Pipelines into a unified local dashboard. Instead of switching between seven different provider UIs, DevOps engineers and SREs get a single view of all their pipelines, with real-time status updates and the ability to trigger or cancel runs without leaving the dashboard.

Built in Rust with Tauri for the desktop application and Axum for headless server deployments, Pipedash runs entirely on your infrastructure with no telemetry or third-party cloud services. Credentials are encrypted using AES-256-GCM with Argon2id key derivation, stored in your OS keyring, encrypted SQLite, or encrypted PostgreSQL — your choice.

The plugin architecture compiles each CI/CD provider into the binary at build time, exposing a clean Rust trait interface that makes adding new providers straightforward. The same core library powers the native desktop app, the Docker web server, and the iOS mobile app, ensuring consistent behavior across deployment modes.

Pipedash supports both SQLite (for individual use) and PostgreSQL (for team deployments behind a VPN), with a setup wizard handling storage selection and optional data migration between backends.

What You Get

• Unified multi-provider dashboard - Monitor GitHub Actions, GitLab CI, Jenkins, Buildkite, Tekton CD, ArgoCD, and Bitbucket Pipelines side by side with real-time status polling and automatic background refresh.
• Trigger and re-run workflows - Initiate new pipeline runs with dynamic parameter forms fetched from each provider’s API — workflow inputs for GitHub Actions, build parameters for Jenkins, pipeline variables for GitLab CI — and replay previous executions with identical parameters.
• Cancel running builds - Abort active pipeline runs across all integrated providers directly from the Pipedash interface without navigating to each provider’s dashboard.
• Encrypted local credential storage - Provider tokens are stored using AES-256-GCM encryption with Argon2id key derivation, via your OS system keyring (macOS Keychain, Windows Credential Manager, Linux Secret Service), encrypted SQLite, or encrypted PostgreSQL — with no data sent to third-party services.
• TOML config-as-code - Define providers, storage backends, refresh intervals, and token references (including environment variable interpolation) in a single TOML file for reproducible, version-controlled deployments.
• Compile-time plugin system - Each CI/CD provider is a Rust crate implementing the Plugin trait, compiled into the binary at build time for security and simplicity; adding a new provider requires implementing a defined interface without touching core application logic.
• Multi-backend storage - Choose between SQLite for personal use or PostgreSQL for team deployments, with a setup wizard for initial configuration and live data migration between backends.
• Cross-platform deployment - Run as a native Tauri desktop app on macOS, Windows, and Linux; as a Docker container serving an embedded web frontend; or as an iOS app — all backed by the same pipedash-core library.

Common Use Cases

• Managing hybrid CI/CD environments - A DevOps engineer monitors GitHub Actions for open-source projects, GitLab CI for internal microservices, and a self-hosted Jenkins instance for legacy builds, all from one Pipedash view without tab-switching.
• Team-wide pipeline visibility behind a corporate firewall - An SRE team deploys Pipedash via Docker Compose with a PostgreSQL backend behind their VPN, giving all developers secure access to aggregated CI/CD status without exposing individual provider tokens to a cloud service.
• Kubernetes workload monitoring with Tekton and ArgoCD - Platform engineers track Tekton pipeline runs and ArgoCD application sync status across multiple Kubernetes clusters, with Pipedash auto-detecting namespaces and filtering by Git organization.
• On-call engineers checking build status from mobile - A developer uses the Pipedash iOS app to monitor GitHub Actions and Bitbucket Pipelines during an incident, checking whether deploys are queued or failed without needing VPN access to internal dashboards.
• Config-as-code CI/CD setup - A platform team defines all Pipedash providers and storage configuration in a checked-in TOML file with environment variable references for secrets, enabling reproducible deployments across staging and production environments.

Under The Hood

Architecture Pipedash uses a three-crate monorepo split between pipedash-core (domain models, application services, storage, and infrastructure), pipedash-desktop (Tauri native app with OS keyring integration), and pipedash-web (Axum HTTP server for headless deployment). The plugin system is defined as a Rust trait that each CI/CD provider implements independently, keeping the core application completely decoupled from provider-specific API logic. Within pipedash-core, a layered architecture separates application services from domain models and infrastructure concerns — database access, secrets management, and HTTP clients each live in distinct modules with explicit dependency flow. Reactivity flows from per-provider background polling loops to the frontend via WebSocket events, while the React layer uses TanStack Query for server state and Zustand for client state, creating a predictable unidirectional data path.

Tech Stack The backend is written in Rust using Axum for HTTP routing, SQLx for async database access against both SQLite and PostgreSQL, and the kube crate with k8s-openapi for Kubernetes integration supporting Tekton and ArgoCD. AES-256-GCM encryption with Argon2id key derivation handles credential security via the aes-gcm and argon2 crates. The frontend uses React 19 with the Mantine UI component library, TanStack Query v5 for server state management, Zustand for client-side state, and Recharts for pipeline metrics visualization, bundled via Vite with SWC compilation. The desktop application wraps this frontend in Tauri v2, providing native OS integrations for system keyring access. TOML-based configuration-as-code is parsed via the toml and toml_edit crates, and the development environment is orchestrated entirely through mise tasks.

Code Quality No automated test suite exists in the repository — neither Rust unit tests nor TypeScript spec files were found, which is the primary quality gap. The codebase compensates with strong structural discipline: Rust uses thiserror for typed error enums, PluginError::NotSupported provides explicit capability signaling, and TypeScript leverages generic type constraints throughout the hook layer. Code formatting is enforced via rustfmt and ESLint with eslint-plugin-simple-import-sort, and the CI pipeline (mise run ci) runs format checks, Clippy linting, and TypeScript type checking. The compiled plugin trait boundary does provide compile-time correctness guarantees across provider integrations, partially substituting for runtime test coverage.

What Makes It Unique Pipedash’s most technically distinctive choice is compiling CI/CD provider plugins statically into the binary rather than loading them dynamically, eliminating runtime plugin security concerns while preserving a clean extensibility interface via the Rust trait system. The same pipedash-core library powers three entirely different deployment targets — native desktop with OS keyring, headless Docker server with encrypted vault, and iOS mobile app — without divergent codebases. The vault password serving dual purpose as both an encryption key and an API bearer token for web deployments is a pragmatic design that avoids separate authentication infrastructure. Filter state is synchronized directly to URL search parameters via useSearchParams, enabling deep-linkable and shareable pipeline views without a dedicated state management layer.

Self-Hosting

Pipedash is released under the GNU General Public License v3.0 (GPL-3.0), a strong copyleft license. This means you can use, modify, and redistribute the software freely, but any modifications you distribute — including running it as a network service that others access — must be released under the same GPL-3.0 terms. For most teams using Pipedash internally behind a VPN or for personal use, the GPL-3.0 imposes no practical restriction, since internal use does not constitute distribution. If you plan to bundle or redistribute Pipedash as part of a commercial product or service offering access to external users, you would need to comply with GPL-3.0 copyleft requirements.

Running Pipedash yourself requires real infrastructure decisions. The Docker deployment path is straightforward — a single container under 30MB embeds both the Rust backend and the compiled frontend, and the provided examples/ directory includes ready-to-use Compose files for both SQLite and PostgreSQL backends. For team use, PostgreSQL adds operational complexity: you are responsible for database provisioning, backups, connection pooling, and upgrades. Token encryption keys are auto-generated on first run and stored in the Docker volume, so losing the volume means losing access to stored credentials. The vault password must be managed carefully for reproducible deployments. Refresh polling intervals are configurable per provider, but you are responsible for staying within each CI/CD provider’s API rate limits.

Pipedash has no paid cloud tier or managed hosting option as of its current release. There is no enterprise support contract, SLA, high-availability configuration, or managed upgrade path available from the project maintainers. Support happens via GitHub Issues from a small contributor base. Compared to commercial CI/CD aggregation products, you give up automatic updates, professionally managed infrastructure, and formal support channels. What you gain is complete data sovereignty — your provider tokens never leave your network — and no per-seat or usage-based pricing.