Perses is an Apache-2.0 dashboard and observability visualisation tool, a Cloud Native Computing Foundation sandbox project written in Go, for platform, SRE and observability teams that want Prometheus metrics, Tempo traces, Loki logs and Pyroscope profiles displayed in one place.

What it is

Perses is first and foremost a dashboard tool used to display a variety of observability data. It currently supports Prometheus for metrics, Tempo for traces, Loki for logs and Pyroscope for profiling, bringing all four observability pillars together in a single application. The project is a CNCF sandbox project and is maintained under the perses organisation, with core plugins living in the separate perses/plugins repository, while dashboard definitions can also be deployed into and read from individual application namespaces as Custom Resource Definitions through the Perses Operator.

The concrete problem it solves is the lack of a shared, standardized definition of a dashboard. Perses is also an initiative to define a standardized dashboard specification, which is intended to foster interoperability across observability tools rather than binding dashboard definitions to one vendor or one rendering engine. Alongside that specification work, it replaces the hand-maintained, UI-only dashboard workflow with a Dashboard-as-Code approach: SDKs, CI/CD libraries, static validation and a native CLI, so dashboards can be reviewed, validated and promoted like any other artifact. The project also provides npm packages that let developers embed Perses panels and dashboards into their own user interfaces, with the Prometheus UI named as one example of where that could apply.

Key capabilities

• Displays four observability pillars in one tool: Prometheus metrics, Tempo traces, Loki logs and Pyroscope profiling.
• Defines an open specification for dashboards, aimed at interoperability across observability tools.
• Ships a plugin architecture that externalizes both plugin loading and plugin implementation, with core plugins maintained in perses/plugins.
• Provides two SDKs for coding dashboards, in Golang and Cuelang, documented through the Dashboard-as-Code getting-started guide in docs/dac/getting-started.md.
• Includes a native CLI for interacting with the API, documented in docs/cli.md.
• Delivers npm packages that allow panels and dashboards to be embedded into third-party UIs.
• Supports Kubernetes-native mode through Custom Resource Definitions, with the Perses Operator handling deployment and reading of dashboard definitions in application namespaces.

Who uses it and how

• Platform and SRE teams that run Prometheus, Tempo, Loki and Pyroscope together and want a single dashboard surface across all four signal types.
• Teams practising GitOps, who keep dashboards in source control, validate them statically and drive them through CI/CD with the CLI and the Golang or Cuelang SDKs.
• Kubernetes operators who deploy dashboard definitions as CRDs into individual application namespaces and read them back per namespace with the Perses Operator.
• Developers embedding observability panels inside their own products by consuming the published npm packages.
• Evaluators can try the hosted online demo at https://demo.perses.dev, inspecting existing dashboards or creating their own resources before committing to an install.

Getting started

Precompiled binaries for released versions are available from the GitHub releases, and using the latest release binary is the recommended way of installing Perses. Each release also carries SBOM artifacts documenting the full set of shipped dependencies.

How it compares

This registry lists no paid product or directly comparable dashboard tool that Perses replaces, so Perses stands alone here among dashboard projects. The only other tools named in the facts are the data sources it reads — Prometheus, Tempo, Loki and Pyroscope — which Perses queries and renders rather than competes with. Its distinguishing position in these facts is the open dashboard specification and the Dashboard-as-Code toolchain built around it.

When to use it — and when not to

A self-hoster has to run the Perses application itself and manage plugin loading and implementation, since the plugin architecture externalizes both; the facts do not specify a database, object storage or SMTP dependency, so those requirements should be confirmed before planning a deployment. Teams that want a fully managed, zero-operations dashboard service, or that need data sources beyond the four currently supported, should wait, because coverage today is Prometheus, Tempo, Loki and Pyroscope only. The install documentation here covers precompiled binaries from GitHub releases, and the facts mention no container image or Helm chart, so container-based deployment paths are outside what this page can confirm; the project also carries 277 open issues and its SDKs are explicitly expected to evolve, though the intent is to add utility functions rather than introduce breaking changes.

docker run --name perses -d -p 127.0.0.1:8080:8080 persesdev/perses

git clone https://github.com/perses/perses.git
cd perses

make build
./bin/perses --config=your_config.yml