This release first comes with a large number of security fixes, several of them critical, so we strongly recommend upgrading as soon as possible.

On the dashboard side, you can now repeat a single panel, define annotations per panel, drag and drop panels between groups and lock the plugin versions used by a dashboard. Prometheus exemplars are supported, the search has been rewritten on the backend, and two new plugins are available: Canvas and JSON.

As usual, this blog post doesn't cover every change. For the complete list, check the changelog.

Security

This release fixes a significant number of security vulnerabilities, several of them critical. Most of them can be exploited without authentication when Perses runs with its default configuration (security.enable_auth: false). We strongly recommend upgrading as soon as possible.

Some of these fixes are breaking changes, check the upgrade guide before upgrading and or the section Breaking changes below for more details.

We also published a security considerations page (#4512) describing how to deploy Perses safely.

Authentication bypass via forged JWTs (GHSA-mpfg-6jh9-3jmg)

When authentication was enabled without setting security.encryption_key (or security.encryption_key_file), Perses fell back to a key hardcoded in its public source code. This key is also used to sign the JWTs, so anyone could forge a valid token for any user, including an admin.

Perses now refuses to start when authentication is enabled and no encryption key is provided.

Server-Side Request Forgery in the datasource proxy (GHSA-58wc-w2cq-7vf3)

The datasource proxy (HTTP and SQL) connected to whatever destination the datasource defined. Combined with the "unsaved" proxy endpoints, Perses could be used to read any service reachable from the server: loopback, cloud metadata endpoints, the Kubernetes API, etc.

The destination of the proxy is now verified when a datasource is saved and before each request, including on every resolved IP address. Loopback, link-local, the cloud metadata endpoints and the Kubernetes API are denied by default. Private networks remain allowed. The restrictions can be adjusted in the new datasource.proxy configuration section:

datasource:
  proxy:
    allowed_networks: ["127.0.0.0/8", "::1/128"]

Arbitrary file read through secrets (GHSA-2qpg-wfx2-frv2)

Secrets can reference files (passwordFile, credentialsFile, clientSecretFile, caFile, certFile, keyFile). These files could be anywhere on the server, so a user able to create a secret could exfiltrate any file readable by Perses through the datasource proxy.

File references are now rejected by default. They are only allowed in the directories listed in the new security.secret_file_allowed_directories configuration.

Caller credentials forwarded to the datasource (GHSA-phr8-237x-w7mj)

The HTTP datasource proxy forwarded the Cookie and Authorization headers of the caller to the datasource. Anyone controlling a datasource could steal the Perses session of its users (including the refresh token) and take over their account.

The Cookie header of the caller is no longer forwarded, and neither is the Authorization header when the native authorization is enabled. To authenticate against a datasource, use a secret or the oauthPassthrough option.

Stored XSS through the datasource proxy (GHSA-8hm2-fqjh-pgj2)

The responses of the datasource proxy are served from the Perses origin, almost unchanged. A malicious datasource could serve HTML and JavaScript running with the session of any user opening a link to it, set cookies on the Perses domain, or redirect users anywhere.

The proxy responses are now sandboxed with a strict Content-Security-Policy, and the headers that apply to the Perses origin (Set-Cookie, CORS headers, absolute redirections, etc.) are removed. As a consequence, the UI of a datasource (e.g. the Prometheus UI) can no longer be browsed through the proxy.

SQL proxy vulnerabilities

Several vulnerabilities have been fixed in the SQL proxy:

• Read-only restriction bypass (GHSA-r457-39g6-wpc6): queries modifying the data or the schema could get through the keyword check. Queries must now start with a read keyword (SELECT, WITH, SHOW, etc.) and are executed in a read-only transaction. MySQL multiStatements, as well as SELECT ... INTO OUTFILE / DUMPFILE, are rejected.
• Arbitrary file read with MySQL/MariaDB (GHSA-92jg-r5jf-x5fh): the allowAllFiles driver option could be enabled from the datasource params, letting the database server read any file of the Perses server. This option, as well as allowCleartextPasswords and allowOldPasswords, is now always disabled.
• MySQL/MariaDB TLS config mix-up (GHSA-jg7f-c7hw-wxgw): two datasources with colliding names could use each other's TLS configuration (CA, client certificate, verification settings). The TLS configuration is now set per connection.

Missing secret authorization in dashboard datasources (GHSA-mc34-vgvh-gpr7)

A user allowed to edit a dashboard, but not to read secrets, could embed a datasource referencing any secret of the project and make the proxy send it to a server they control. Perses now checks that the user can read the secret used by a datasource embedded in a dashboard.

Wiping the database with a single request (GHSA-j8hv-r356-hfw6)

With the file system database, deleting the project .. (DELETE /api/v1/projects/..) deleted the entire database. The name of the resource in the URL was never validated. Every parameter of the URL is now validated before being used.

Path traversal in the file system database (GHSA-63qw-3pm6-j4f3, GHSA-2wxp-jhwc-h2ff)

The fix released in v0.54.0 for CVE-2026-63445 could be bypassed with a project named .. (e.g. GET /api/v1/variables?project=..), returning the whole database. The anonymous endpoint POST /api/validate/dashboards was also using the metadata.project of the dashboard without any validation.

The project name is now validated for every HTTP method and in the body of the requests, and the file system database itself rejects any key that would escape its directory.

Note that these issues (as well as the previous one) don't affect the SQL database.

Breaking changes

Removal of the package @perses-dev/core

As announced in v0.54.0, @perses-dev/core is no longer published (#4325). Its code has been dispatched in @perses-dev/spec, @perses-dev/client, @perses-dev/plugin-system and @perses-dev/components. It is also no longer shared with the plugins at runtime (perses/shared#246), so plugins still importing it must be migrated.

Dependency upgrades: React 17 dropped, Node 24, TypeScript 7 and end of CommonJS

The frontend toolchain has been modernized across all the repositories:

• React 17 is no longer supported (#4391, perses/shared#269, perses/plugins#790), as planned in the roadmap.
• Node.js 24 (LTS) and ES2023 are now the target (#4380, perses/shared#248, perses/spec#78, perses/plugins#779).
• Packages are published as ESM only: the CommonJS output has been removed.
• TypeScript 7, as well as newer versions of Zod and React Hook Form (#4421).

If you embed Perses in your own application, you now have to register the Perses packages shared with the plugins before rendering your app (perses/shared#268):

import * as PersesClient from '@perses-dev/client';
import * as PersesComponents from '@perses-dev/components';
import * as PersesDashboards from '@perses-dev/dashboards';
import * as PersesExplore from '@perses-dev/explore';
import * as PersesPluginSystem from '@perses-dev/plugin-system';
import { registerHostSharedModules } from '@perses-dev/plugin-system';
import * as PersesSpec from '@perses-dev/spec';

registerHostSharedModules({
  '@perses-dev/spec': PersesSpec,
  '@perses-dev/client': PersesClient,
  '@perses-dev/components': PersesComponents,
  '@perses-dev/plugin-system': PersesPluginSystem,
  '@perses-dev/explore': PersesExplore,
  '@perses-dev/dashboards': PersesDashboards,
});

Removal of the old dashboard and datasource specification

Since v0.54.0, the dashboard and datasource specifications live in perses/spec. The deprecated copies remaining in Perses have been removed (#4326): the Go packages pkg/model/api/v1/{common,dashboard,datasource,plugin,variable} and their CUE equivalents. If you still import them, switch to the ones provided by github.com/perses/spec (e.g. github.com/perses/spec/go/dashboard).

Go SDK: datasource.Selector is now a union type

A datasource selector can now reference a variable, which is serialized as a plain string (e.g. "$myDatasource") (#4545). As a result, datasource.Selector no longer has the Kind and Name fields, but a Static or a Variable selector. Use the new constructors instead of a struct literal (#4557):

// Before
sel := &datasource.Selector{Kind: "PrometheusDatasource", Name: "myPrometheus"}

// After
static := datasource.NewStaticSelector("PrometheusDatasource", "myPrometheus")
variable, err := datasource.NewVariableSelector("myDatasource")
// Or let the SDK detect a variable reference ("$foo" or "${foo}")
auto, err := datasource.NewSelector("PrometheusDatasource", name)

The official plugins have been updated (perses/plugins#857): their Selector helper now detects variable references, and a new VariableSelector helper is available. If you maintain your own datasource plugin with a Selector helper, update it the same way.

Likewise, the deprecated CUE package cue/common/proxy has been removed from perses/shared (perses/shared#327). Use github.com/perses/spec/cue/datasource/proxy/http and github.com/perses/spec/cue/datasource/proxy/sql instead.

API changes in the TypeScript packages

If you develop plugins or embed Perses, these changes in the @perses-dev/* packages may require an update:

• useDeepMemo and useMemoized are removed, use React useMemo instead. The spec of a Resource and the cell values of TableColumnConfig are now unknown instead of any (perses/shared#310).
• useId is no longer exported from @perses-dev/components, use React useId() instead (perses/shared#348).
• Zod schemas are typed with z.ZodType<T, T> instead of z.ZodType<T> or the deprecated z.ZodSchema<T> (perses/shared#282, perses/spec#95).
• The PanelEditorValues type and its schema are removed from @perses-dev/spec, use the ones from @perses-dev/plugin-system (perses/spec#59).
• Annotations are now fetched on demand, only by the panels displaying them (perses/shared#330). The annotationState store field and the setAnnotationState action are removed, and usePanelAnnotationsWithData no longer returns hidden annotations.

Security changes

Some of the security fixes require a configuration change on your side:

• Encryption key: if authentication is enabled, security.encryption_key (or security.encryption_key_file) must be set, otherwise Perses won't start. If you were relying on the default key, the secrets previously stored can no longer be decrypted and must be re-created, and users will have to log in again.
• Datasource proxy destinations: datasources pointing to loopback, link-local addresses, cloud metadata endpoints or the Kubernetes API are now rejected. If you rely on such datasources (e.g. a Prometheus running next to Perses on localhost), allow them through datasource.proxy.allowed_networks or datasource.proxy.allowed_hosts. URLs containing credentials (https://user:password@host) are also refused: use a secret instead.
• Files referenced in secrets: they are rejected by default. List the directories containing them in security.secret_file_allowed_directories.
• Resource names: a name can no longer contain .., nor start or end with . (perses/spec#102). Rename the resources using such a name.
• Proxy headers: the Authorization header of the caller is no longer forwarded to the datasource when the native authorization is enabled, and the UI of a datasource can no longer be browsed through the proxy.

See the upgrade guide for more details.

Performance improvements

This release comes with several performance improvements on the backend. The numbers below come from the benchmarks shared in the corresponding pull requests.

Datasource proxy reuses its connections

Until now, the proxy created a new HTTP transport for every proxied request, so no TCP or TLS connection was ever reused. Perses now keeps one transport per saved datasource (#4521), which is particularly visible with HTTPS datasources:

It also uses ~4x less memory per request. On a real network, each request additionally saves the round trips of the TCP and TLS handshakes. The connection limits can be tuned with the new datasource.proxy.http configuration:

datasource:
  proxy:
    http:
      max_conns_per_host: 0 # 0 = no limit
      max_idle_conns: 100
      max_idle_conns_per_host: 10

Faster native authorization

The permission cache of the native authorization is rebuilt at startup, periodically, on every RBAC change and on the first login of every OAuth/OIDC user. Its build now runs in linear time (#4540). With 10,000 users and 1,000 projects:

The cache is now also an immutable snapshot read without any lock (#4537). It fixes a deadlock that could hang every authorization check until a restart, and makes permission checks under concurrent load ~7x faster (from ~145 ns to ~20 ns per check).

Faster plugin extraction at startup

Plugin archives are now extracted in parallel (#4507), and the ones already extracted are skipped (#4534). With the default plugins (32 archives, ~9,000 files), the extraction step goes from ~1–2 s to ~1 ms when the archives are already extracted, and the whole plugin initialization from ~1.35 s to ~0.3 s.

Skipping the archives benefits binary installations and deployments where the plugin folder is kept between restarts (e.g. mounted on a volume). With the official container image and its default setup, every new container still extracts all archives, but in parallel.

Better browser caching of static assets

Content-hashed JS and CSS bundles (#4475), as well as fonts and images from the app and the plugins (#4533), are now served as immutable assets. Browsers no longer download or revalidate them on every page load.

Dashboard lock mode

Dashboards don't pin the version of the plugins they use, so a plugin upgrade can change how a panel looks. The new lock mode (perses/shared#243) pins every plugin of a dashboard to the latest installed version. When a newer version is available, a button lets you update the plugins, with a preview of the change based on the first panel using it. If a pinned version is no longer installed, an error is displayed.

The panel type selector also shows the plugin version when several versions are installed.

The feature is disabled by default (#4370):

frontend:
  enable_lock_mode: true

Drag and drop panels between panel groups

The grid layout library has been replaced by Snapgrid (perses/shared#296), so panels can now be dragged from one panel group to another. Drag and drop in lists (e.g. item actions) is also only triggered from the drag handle, so you can select text again (perses/shared#335).

Panel repeat

Until now, only a panel group could be repeated over the values of a variable. A single panel can now be repeated as well (perses/spec#32, perses/shared#149). In the Layout tab of the panel editor, choose the variable, the alignment (horizontal or vertical) and the maximum number of panels per row or column:

layouts:
  - kind: Grid
    spec:
      items:
        - x: 0
          y: 0
          width: 12
          height: 6
          content:
            $ref: '#/spec/panels/cpu'
          repeatVariable:
            value: instance
            alignment: horizontal
            maxPer: 4

Only the selected values are used, and a group repeat takes precedence over a panel repeat. Repeated panels are also supported by the Grafana migration (#4328).

Panel-level annotations

v0.54.0 introduced annotations at the dashboard level. They can now be defined on a panel as well (perses/spec#61, perses/shared#206, #4356). The panel displays the dashboard annotations plus its own ones.

A new Annotations tab is available in the panel editor for the plugins supporting it. For now, only the TimeSeriesChart does (perses/plugins#754). Panel annotations are validated by the backend like the dashboard ones (#4299), and the Go SDK can now build both of them (#4448).

Exemplars support

The Prometheus datasource can now fetch exemplars (perses/plugins#799). It is disabled by default and must be enabled per datasource:

kind: GlobalDatasource
metadata:
  name: prometheus
spec:
  plugin:
    kind: PrometheusDatasource
    spec:
      exemplars:
        enable: true
      proxy:
        kind: HTTPProxy
        spec:
          url: https://prometheus.example.com

Exemplars are then fetched with range queries and displayed by the TimeSeriesChart as diamonds on top of their series (perses/plugins#800). Hovering one shows its labels (e.g. the trace ID), value and timestamp, and clicking it pins the tooltip (perses/shared#278).

Improved search experience

The search is now done by the backend, through the new endpoint /api/v1/search/dashboards (#4355). Dashboards are indexed in memory and matched with a fuzzy search. With a SQL database, every Perses instance periodically checks for changes to keep its index in sync. By default, the name and the display name are indexed, but you can index any attribute, like the panel names:

search:
  index_keys:
    dashboard:
      - metadata.name
      - spec.display.name
      - spec.panels.@dig:display.name

The project view also uses this endpoint to list the dashboards, without loading their full definition (#4366), and its search bar now matches tags too (#4446).

Finally, the important dashboards of the home page can be organized in groups, and an entire project can be marked as important (#4506). The previous flat list is still supported but deprecated.

frontend:
  important_dashboards:
    - title: Perses demos
      dashboards:
        - project: perses
        - project: testing
    - title: Quick links
      description: Highlighted dashboards
      dashboards:
        - project: perses
          dashboard: nodeexporter

Authentication & authorization

• Roles from OAuth/OIDC claims (#4172): roles can be assigned from the claims of the identity provider token, without creating any RoleBinding. Without project, the role is a GlobalRole.

  security:
    authentication:
      providers:
        oidc:
          - slug_id: keycloak
            # ...
            claims:
              - claim_name: roles
                mappings:
                  - claim_value: admin
                    role_name: admin
                  - claim_value: ops
                    role_name: editor
                    project: platform

• OAuth pass-through (#4404): with oauthPassThrough: true in its HTTPProxy, a datasource is queried with the OAuth/OIDC token of the current user. The token is refreshed when needed.

• Kubernetes impersonation (#4339): with the Kubernetes authorization, the Impersonate-User header is honored if the caller is allowed to impersonate this user.

• Pre-hashed passwords (#4423): users can be provisioned with a bcrypt hash (spec.nativeProvider.passwordHash) instead of a cleartext password.

• OIDC login property (#4468): like the OAuth provider, the OIDC provider supports custom_login_property to choose the user info field used as login (e.g. preferred_username).

HTTP proxy improvements

The HTTP proxy used by the datasources received a lot of attention in this release: it is safer, faster and more configurable.

Header filtering policies

Some datasources don't play well with certain headers sent by the browser or added by Perses (e.g. X-Forwarded-For). The HTTPProxy spec now supports two optional header policies (#4428):

• allowHeaders: only the listed headers are forwarded to the datasource.
• dropHeaders: the listed headers are removed, and the others are forwarded.

kind: Datasource
metadata:
  name: prometheus
  project: my-project
spec:
  default: true
  plugin:
    kind: PrometheusDatasource
    spec:
      proxy:
        kind: HTTPProxy
        spec:
          url: https://prometheus.example.com
          dropHeaders:
            - X-Forwarded-For
            - User-Agent

Header names are case-insensitive and only one of the two lists can be set. The filtering is applied after the headers defined in the datasource, but before the secret authentication, so there is no need to allow Authorization when the datasource uses a secret.

Configurable timeout

The HTTPProxy spec also accepts a new optional timeout field, available in the datasource editor as well (#4525). To avoid letting users hold goroutines and sockets against unreachable hosts for too long, the timeout of a datasource is bounded by the server configuration:

datasource:
  proxy:
    http:
      default_timeout: 30s # used when the datasource doesn't define a timeout
      max_timeout: 1m # highest timeout a datasource can define

A datasource defining a timeout greater than max_timeout is rejected when it is saved, and its timeout is clamped when it is used.

Security hardening

As described in the Security section, the proxy has been hardened in many ways:

• its destination is verified against a list of allowed and denied networks/hosts (loopback, link-local, cloud metadata endpoints and Kubernetes API denied by default), configurable through datasource.proxy. The allowed schemes can be restricted with datasource.proxy.http.allowed_schemes;
• the Cookie header of the caller is never forwarded, and neither is the Authorization header when the native authorization is enabled. An Authorization header defined in the headers of a datasource is ignored: use a secret instead;
• its responses are sandboxed with a strict Content-Security-Policy, and the headers applying to the Perses origin are removed.

Some of these changes may require a configuration update, check the Security changes section and the proxy documentation for more details.

Connection reuse

Finally, the proxy now keeps one HTTP transport per datasource and reuses its connections, making HTTPS requests up to ~23x faster. See Datasource proxy reuses its connections for the numbers and the new connection limits.

Refresh interval configuration

The auto-refresh options of the dashboards can now be configured (#4432), or the auto-refresh can be disabled entirely (#4338). In that case, the interval picker is hidden and the refreshInterval of the dashboards, as well as the ?refresh= URL parameter, are ignored.

Similarly, administrators can define the default timezone, theme and number of rows per page, used when a user hasn't chosen their own (#4268).

frontend:
  auto_refresh:
    disable: false
    options: ["0s", "30s", "1m", "5m"]
  default_user_preferences:
    timezone: UTC
    theme: dark
    rows_per_page: 50

Provisioning improvements

• Perses can now watch the provisioning folders and apply the changes right away, instead of waiting for the next interval (#4136). Resources are also only updated when they actually changed, which avoids unnecessary writes and ever-increasing versions.
• A provisioning file can contain several resources separated by --- (#4332).

provisioning:
  enable_watch: true
  folders:
    - /etc/perses/provisioning

CLI improvements

• The new command percli dac watch rebuilds your Dashboard-as-Code files on every change, including the dashboards depending on a modified library file (#3903). Combined with the provisioning watch mode, it gives you a live reload of your dashboards.
• percli dac preview supports the --create-project flag, like percli apply (#4413).

Dashboard and plugin schemas API

Perses now exposes the CUE schemas of the dashboards and of the installed plugins (#4505). It is particularly useful for tools generating dashboards, like the Perses MCP server:

• GET /api/v1/schemas/dashboards: the complete dashboard schema, including the plugin schemas.
• GET /api/v1/schemas/plugins: the schemas of all plugins.
• GET /api/v1/schemas/plugins/<plugin_name>: the schema of a single plugin, with the optional version and registry query parameters.

Datasource improvements

The datasource editor has a new Test Connection button to check the datasource is reachable before saving it (#4396, perses/shared#99). It is available for Prometheus (perses/plugins#620), OpenSearch (perses/plugins#797) and AlertManager (perses/plugins#798).

The Kubernetes datasource discovery can also mark a discovered datasource as the default one, based on its labels or annotations (#4368):

datasource:
  global:
    discovery:
      - name: prometheus
        kubernetes_sd:
          # ...
          default:
            enable: true
            labels:
              app.kubernetes.io/name: prometheus

New plugins

Canvas

The Canvas panel (perses/plugins#729) is a free-form diagram editor to build weathermap-like visualizations. Place nodes, connect them with edges and add background shapes or images. Nodes and edges can be bound to a query: their color then follows thresholds and the edge thickness can scale with the value.

Json

The new JSON datasource and query (perses/plugins#770) can query any HTTP endpoint returning JSON, with GET or POST, query parameters and variables. The response can be transformed with a JSONata expression, and the result displayed in a Table panel.

Plugin improvements

• TimeSeriesChart:
  • the color palette can be selected again (perses/plugins#845). Auto keeps the current color by series name, the categorical palettes give more distinct colors.
  • rendering is faster, especially with many series (perses/plugins#832).
• StatChart: multiple series are laid out in a grid adapting to the panel size, instead of a single row (perses/plugins#812, perses/plugins#814). Their values and legends also share the same font size, which can be customized (perses/plugins#778).
• Table: sorting can be enabled for all columns at once (perses/plugins#759), and the new PivotByLabel transform turns series into a time × label matrix (perses/shared#288).
• BarChart: colors can be overridden with regexes on the series or bar names (perses/plugins#774).
• PieChart: the inner and outer radius can be configured, e.g. to display a donut (perses/plugins#823).
• Markdown: external links open in a new tab (perses/plugins#815).
• Prometheus: a query can be executed as an instant query, regardless of the panel (perses/plugins#752).
• Pyroscope: profiles are queried through the Connect API instead of the legacy /render endpoint (perses/plugins#763). The minimum step can be configured on the datasource (perses/plugins#810), and the profile types and labels proposed are restricted to the selected service (perses/plugins#820, perses/plugins#835).

TimeSeriesChart color palette	StatChart grid layout

Other improvements

• Duplicate a dashboard into another project (#4536), including from a project where you only have read access.

  

• Open in a new tab: the project and admin tabs, as well as the ephemeral dashboards, are now real links (#4252).

• Page title: the browser tab title now reflects the current page (#4489).

• Collapsed panel groups show the number of panels they contain (perses/shared#309).

• Custom unit label: a panel can display its own unit label (e.g. trx/s) while keeping the formatting of a standard unit (perses/shared#297).

• Grafana migration: the default time range, the refresh interval and the timezone of the Grafana dashboard are kept (#4555). Table thresholds are migrated to cell settings (perses/plugins#808), and datasource variables for Jaeger and OpenSearch are supported (perses/plugins#769).

• Compressed requests: the API accepts request bodies compressed with gzip (Content-Encoding: gzip) (#4381).

• Custom fetch: apps embedding Perses can override the fetch used by the client and the datasources through a fetch provider, e.g. to add custom headers (perses/shared#214, perses/shared#316, perses/plugins#854).

First of all this release includes several security fixes that patches some breach in the permission system included in Perses, so we strongly recommend to upgrade to this version as soon as possible.

Then, you will be happy to know that this release includes new plugins: Jaeger, GreptimeDB, Splunk, LogExplorer, AlertManager and OpenSearch.

As adding more plugins is increasing the size of the container image, likely we will remove some of them in future release. It does not mean we will remove the support for these plugins, it is just we won't include them into the default image. You will have to add them manually. The drop will occur once we are able to provide a good way to add plugins to an existing installation without having to rebuild the image. In the meantime, if you don't want to use these plugins, you can choose to enable or disable them by configuration.

We are also happy to announce it includes the long awaited sub-folder system to better organize your dashboards and improve the accessibility by adding keyboard shortcuts.

This release is also the last release for the package @perses-dev/core that is now deprecated. For that we are introducing two new packages @perses-dev/spec and @perses-dev/client.

• @perses-dev/spec contains the dashboard and datasource specifications.
• @perses-dev/client contains the client to interact with the Perses API.

The code from @perses-dev/core has been dispatched in these these two packages and in others (like @perses-dev/plugin-system and @perses-dev/components) to better separate the concerns and make it easier to maintain.

Finally, thank you to all the contributors who made this release possible, you are more and more, and we are really happy to see the community growing and contributing to make Perses better and better!

As usual, this blog post does not cover all the changes and improvements included in this release. We are only talking about the changes that should interest you the most. If you want to have a complete list of all the changes, please refer to the changelog

Security issues

On top of the various features and improvements, we have fixed several security issues in this release that compromised the permission system of the Perses application. We strongly recommend to upgrade to this version as soon as possible.

Use query parameter project to list resources without having access to (CVE-2026-63458)

In previous versions, it was possible to list resources (dashboards, datasources, etc.) that you don't have access to by using the query parameter project in the API.

For example, if you have access to the project project-a but not to project-b, you could list all dashboards in project-b by calling the API endpoint /api/v1/dashboards?project=project-b. This would return a list of dashboards in project-b even if you don't have access to that project.

Now, if you try to list resources that you don't have access to, you will get a 403 Forbidden error.

Unvalidated project parameter enables filesystem path traversal (CVE-2026-63445)

In previous versions, it was possible to use the project query parameter to access files outside the Perses installation directory. This could be exploited by an attacker to read sensitive files on the server.

It was also possible to use this query parameter to get access to other resources contained in the database by using a project name that contains a path traversal sequence (e.g. ../secrets).

For example /api/v1/dashboards?project=../projects returns the list of the project while it must not return anything.

Now, if you try to use a project name that contains a path traversal sequence, you will get a 400 Bad Request error.

Note that this attack is not possible if you are using an SQL database instead of the default fileSystem database.

Missing authorization in datasource proxy allows cross-scope secret disclosure (CVE-2026-63199)

In previous versions, it was possible to contact datasources protected by secrets that you don't necessary have access to by using the datasource proxy.

This was because the datasource proxy did not check if you have access to the secret used to connect to the datasource while testing the connection to the same datasource.

Now, if you are creating a datasource or testing a connection to a datasource, the datasource proxy will check if you have access to the secret used to connect to the datasource. If you don't have access to the secret, you will get a 403 Forbidden error.

Introduction of the Perses specification

We have created a new repository called perses/spec that contains the Dashboard and Datasource specifications in different languages (Go, TypeScript, Cuelang).

The goal of this repository is to provide a single source of truth for the specifications and make it easier for developers to work with them in different programming languages, independently of the Perses project.

The specifications are now used in the Perses app, the Go and CUE SDKs, and the CLI. This means that if you use the SDKs and/or the CLI, you will need to update your code to use the new specifications and upgrade the CLI to v0.54.0.

Package @perses-dev/core deprecation

As part of the introduction of the Perses specification, we are deprecating the package @perses-dev/core. We have created a final version of this package that is compatible with the new specifications and will be available in the npm registry. However, we recommend migrating your code to use the new specifications instead of using this package.

Also, if you are using the @perses-dev/core package in your code, you may be using more than just the specifications. In this case, you will also need to update your imports to use the new @perses-dev/client package.

Please read the migration guide for more details about how to migrate your code to use the new specifications and the new package.

Enable or disable plugins through configuration

As we are adding more and more plugins to Perses, we have introduced a new configuration option to enable or disable plugins. This gives users more fine-grained control over which plugins are available in their Perses instance and reduces noise and issues caused by unused plugins.

For example, with the following configuration:

plugin:
  disabled:
    - "pyroscope"
    - "victoriaLogs"
    - "clickHouse"
    - "tempo"

Prometheus will be the only datasource enabled in the default Perses installation.

Another way to achieve the same result is to explicitly enable only the plugins you want to use:

plugin:
  enabled:
    - "prometheus"

In this example, only the Prometheus plugin will be enabled and all other plugins will be disabled.

Note that, a consequence of this configuration is that every panels, variables and queries are also disabled.

This also means that if you add a new plugin in the future, it will be disabled by default, and you will need to explicitly enable it in the configuration.

Annotations

Perses now supports annotations, which add information such as events to panels.

Panels must support annotations; for now, only the TimeSeries Chart panel does. In addition, only annotations based on Prometheus PromQL are supported. However, thanks to the Perses plugin architecture, support for annotations can easily be added to any datasource (as source of data) or panel (for the display).

Keyboard shortcuts

Perses v0.54.0 introduces built-in keyboard shortcuts to help you navigate and operate dashboards faster without having to using a mouse. Press ? anywhere in the UI to open the shortcuts help modal, which lists all available shortcuts grouped by category.

Some highlights:

• ? — Open the keyboard shortcuts help modal
• Ctrl/⌘ + K — Open the search dialog
• G + H — Go to the Home page
• Ctrl/⌘ + S — Save the current dashboard
• D + M — Toggle between edit and view mode
• E — Edit the focused panel (in edit mode)
• V — Toggle fullscreen on the focused panel

Keyboard shortcuts are enabled by default. To disable them, set the following in your Perses configuration:

frontend:
  enable_keyboard_shortcuts: false

Sub-folder support

Perses now supports folders — a way to organise dashboards within a project using a tree structure. A folder's spec.items can contain both dashboard references and nested subfolders, allowing you to mirror how your teams structure their observability content.

The project's dashboard list displays dashboards in a tree view, where you can browse, create, edit, and delete folders and subfolders. The same operations are available through the API and CLI (percli apply, percli get folder, etc.).

For example, the demos folder visible in the screenshot above is defined as:

{
  "kind": "Folder",
  "metadata": {
    "name": "demos",
    "project": "perses"
  },
  "spec": {
    "items": [
      {
        "kind": "Dashboard",
        "name": "demo"
      },
      {
        "kind": "Dashboard",
        "name": "benchmark"
      },
      {
        "kind": "Folder",
        "name": "infrastructure",
        "items": [
          {
            "kind": "Dashboard",
            "name": "nodeexporter"
          }
        ]
      }
    ]
  }
}

New plugins

OpenSearch

This version of Perses now ships a bundled OpenSearch datasource along with a LogQuery plugin. Users can now query and view their logs directly in a Perses dashboard, right next to the other panels with metrics and traces.

Connecting to an existing OpenSearch cluster is easy, using either a proxy or a direct connection. The recommended setup routes requests through the Perses backend proxy: the browser talks to Perses and Perses talks to OpenSearch, so any credentials stay server-side and you don't need to enable CORS on your cluster. A direct connection is also available for local experimentation.

Logs are queried with PPL (Piped Processing Language). You add a Logs Table panel, pick the OpenSearch Log Query query type, point it at an index pattern, and write a PPL query — for example, showing the most recent ERROR lines from a service.

Results are rendered as log entries, with every other column in the row kept as a label so you can filter and display fields like service.name, severityText, or traceId. You can drop several log panels on a single dashboard. For instance, a broad "Recent Logs" view alongside a filtered "Error Logs" one.

A couple of things happen automatically to make this feel native. Queries are bound to the dashboard's current time range. The plugin injects a timestamp filter for you, so the logs follow the time picker (you can turn this off per query). And because OpenSearch indices are schema-flexible, the plugin auto-detects the timestamp and message fields from common names, with per-query overrides when your index uses different ones. Since traceId is just another field, you can even setup an OpenSearch logs panel next to a Tempo or Jaeger trace panel on the same dashboard and pivot from a trace straight to the logs it produced.

Jaeger

This release adds support for Jaeger. With this integration, you can run trace queries against Jaeger from Perses dashboards or explorer.

GreptimeDB

This release adds support for GreptimeDB as a datasource in Perses.

GreptimeDB is an open-source observability database built for Observability 2.0 — treating metrics, logs, and traces as one unified data model (wide events) instead of three separate pillars.

With this integration, you can run log, trace, and time series queries against GreptimeDB directly from Perses dashboards.

The images below show a dashboard example and the corresponding query editors.

GreptimeDB Log Query	GreptimeDB Time Series Query

Splunk

Perses now supports Splunk as a datasource, bringing Splunk's search capabilities directly into your Perses dashboards.

The Splunk plugin lets you connect to Splunk Enterprise or Splunk Cloud and query data using SPL (Splunk Processing Language) — the same query language you already use in Splunk. Once connected, you can visualize results as time series charts or explore raw log data, all within the Perses UI.

• Time Series Queries - Run SPL queries (e.g., timechart) and render results in Perses panel that accepts time series data.
• Log Queries - Retrieve and display log results from Splunk indexes directly in a logs panel.

TimeSeries	Logs

Alertmanager

Perses now supports Alertmanager as a datasource. This allows you to visualize and manage alerts and silences directly from a Perses dashboard.

• The new Alert Table allows you to view, search, group, filter and silence alerts. It also allows to confgure custom columns and label coloring, as many alert queries can be included for a single table it also supports deduplication.
• The new Silence Table allows you to view, search and expire silences. It also allows to configure its columns.

Alerts	Silences

Log Explorer

Perses has been extended with a generic Log Explorer. This allows you to visualize and explore logs from any datasource that supports logs, such as Loki, VictoriaMetrics, ClickHouse, GreptimeDB, etc.

This is a really great addition to Perses, as it will avoid the need to implement an explorer for each datasources supporting logs.

We are thinking about doing the same for traces in the future, but we are still evaluating the best approach to do so.

These changes have been thinking carefully to improve the overall user experience and maintainability of Perses. We hope even if it will make the upgrade process a bit more complex, you will stay with us and enjoy the benefits of these improvements.

While you can read this blog post to have details about the changes and how to upgrade, we are also providing a migration guide that is more condensed and focused on the steps required to upgrade from previous versions to v0.53.0.

On a different topic, we are happy to being able to list Logz.io as a new officially company using Perses in production. Welcome to the Perses community!

If you are a company using Perses or contributing to it and want to be listed as an adopter, please follow the guideline. It is always great to see more and more companies trusting Perses for their monitoring needs. And it will help us to grow the community and make Perses even better.

As usual, this blog post does not cover all the changes and improvements included in this release. We are only talking about the changes that should interest you the most. If you want to have a complete list of all the changes, please refer to the changelog

Introduction of plugin version and registry

To enhance the management of plugins specially when dealing with upgrading a plugin version that may introduce breaking changes, we introduced a new field in the plugin specification called metadata. It includes a version field that allows to specify the version of the plugin and the registry field that indicates the source registry of the plugin.

Now a plugin specification looks like this:

kind: TimeSeriesChart
metadata:
  version: v0.1.0
  registry: perses.dev
spec:
# ... rest of the plugin spec

Note that the version is following the semantic versioning format (semver) and this is enforced during the loading of the plugin.

This change is important as it will allow in the future to manage multiple versions of the same plugin and facilitate the migration from one version to another. We are planning to introduce automatic migration tools in future releases to help users upgrade their plugins seamlessly. Excepting if a plugin is introducing breaking changes that cannot be automatically handled, the upgrade process will be handled by the Perses backend using cuelang script contained in the plugin package.

What does it change?

For end users using the Perses application, this change is transparent and does not require any action.

However, for plugin developers, you will need to update the CLI to the last version. This is required as the API handling the load of the plugins in development has changed. Therefore, previous versions of the CLI won't be able to send the data to the server to load plugin in development. The error returned by the server will be 405 (Method Not Allowed). (see https://github.com/perses/perses/issues/3789)

If you want to see the changes and more details regarding how it is implemented, they are available in this PR: https://github.com/perses/perses/pull/3711

TLS config changes

We are introducing a breaking change in the TLS configuration to have a consistent syntax to define TLS settings across all data-sources specifications and across all backend sub configurations.

The previous version was mixing two syntaxes to set TLS across the various possible configuration that could lead to confusion (camelCase and snake_case). This breaking change is impacting only the SQL database configuration.

In the SQL configuration, if the tls_config is used, then you should change your config like that:

ca_file -> caFile
cert_file -> certFile
key_file -> keyFile
server_name -> serverName
insecure_skip_verify -> insecureSkipVerify
min_version -> minVersion
max_version -> maxVersion

User used in the container

In order to simplify the build of the docker image, we have changed the default user used in the container from nobody to nonroot. As a based image we are using now gcr.io/distroless/static-debian12:non-root instead of ggcr.io/distroless/static-debian12:latest, which gives us a non-root user by default.

What does it change?

This change can impact users that is using as a database the file system inside the container, specially when running the container with docker (not within Kubernetes). In that case, you should ensure that the nonroot user has the right permissions to read and write into the database folder. If this is not the case, when upgrading the image, you will face permission errors when Perses is trying to load the data coming from the file system.

Authentication changes

A new OIDC logout endpoint has been added to the API, allowing users to log out both from Perses and from their OIDC provider, respecting the OpenID Connect RP-Initiated Logout 1.0 specification. This is mainly used by the frontend to ensure a proper provider-side logout when a user signs out.
The feature is currently in beta and disabled by default. It has been successfully tested with Azure AD and Keycloak, so feel free to try it out.

We also introduced several improvements to the generic OIDC/OAuth2 provider system:

• The apiPrefix configuration is now correctly applied during login redirections.
• The OAuth2/OIDC state parameter is now more secure, enabling compatibility with providers such as Authelia.

Improving "Run Query" button behavior in MultiQueryEditor

What does it change?

If you are developing plugin specially query plugin or embedding MultiQueryEditor in your app, these changes will impact you, and you need to follow these guidelines.

MultiQueryEditor component has a new mandatory method: onQueryRun. It will be called when the user click on the button "Run Query". It's useful if you want to execute a query only when this button is clicked and not on every onChange (previous Perses behavior). Now the onChange method is always called when something change in the editor. On the Perses app, queries are only executed when the user click on the "Run Query" button, however changes are still saved if user save the dashboard without clicking on "Run Query". But embedded use-cases might want to execute queries on every change, so this new behavior allows both use-cases.

In parallel, the caching of queries has been greatly improved to avoid memory leaks on dashboard refresh. More info can be found in related PR: #3518 And queries errors are now displayed at the query level (before it was only displayed at the panel level, could be hard to know which queries are causing issues).

About the breaking change, your code should change from this:

export function FooExplorer(): ReactElement {
    const {
        data: {queries = []},
        setData,
    } = useExplorerManagerContext<FooExplorerQueryParams>();

    return (
        <Stack gap={2} sx={{width: '100%'}}>
            <MultiQueryEditor
                queryTypes={['ProfileQuery']}
                queries={queries}
                onChange={(newQueries) => setData({queries: queryDefinitions})}
            />
            <FooPanel queries={queries}/>
        </Stack>
    );
}

to this:

export function FooExplorer(): ReactElement {
    const {
        data: {queries = []},
        setData,
    } = useExplorerManagerContext<FooExplorerQueryParams>();

    const [queryDefinitions, setQueryDefinitions] = useState<QueryDefinition[]>(queries);

    return (
        <Stack gap={2} sx={{width: '100%'}}>
            <MultiQueryEditor
                queryTypes={['ProfileQuery']}
                queries={queryDefinitions}
                onChange={(newQueries) => setQueryDefinitions(newQueries)}
                onQueryRun={() => setData({queries: queryDefinitions})}
            />
            <FooPanel queries={queries}/>
        </Stack>
    );
}

Variable migration changes

We realized variable migration script could be simplified & better follow CUE's good practices by replacing condition blocks by constraints defined on the variable object. However to enable this we had to introduce a breaking change*: where previously such schema was describing the remapping of a Grafana variable object named #var, it is now called #grafanaVar. Thus, if you had defined a schema looking like this:

package migrate

import "strings"

#var: _ 

if #var.type == "custom" || #var.type == "interval" {
    kind: "MyVariable"
    spec: {
        values: strings.Split(#var.query, ",")
    }
}

..the minimum change you need to do is this renaming:

package migrate

import "strings"

#grafanaVar: _ 

if #grafanaVar.type == "custom" || #grafanaVar.type == "interval" {
    kind: "MyVariable"
    spec: {
        values: strings.Split(#grafanaVar.query, ",")
    }
}

Then it is recommended to refactor to something like this:

package migrate

import "strings"

#grafanaVar: {
    type: "custom" | "interval"
    query: string
    ...
}

kind: "MyVariable"
spec: {
    values: strings.Split(#grafanaVar.query, ",")
}

*We believe the trade‑off was worth introducing this breaking change, as we expect very few (if any) people to have written such variable migration schemas outside of the Perses organization. However, if you are impacted, please reach out to us! Learning more about our community helps us make better future decisions by having a clearer understanding of potential impacts.

Introducing i18n support

This new version is introducing internationalization (i18n) support in the frontend, allowing to easily add new languages and provide a better experience for non-English speaking users. The i18n implementation is based on the widely used react-i18next library, which provides a powerful and flexible solution for managing translations in React applications.

For the moment, the il8n is really limited as it only contains a few translations for few languages. The main goal of this change is mainly to get the i18n support in place and have a framework to easily add new translations in the future.

Kubernetes Auth

This release introduces Kubernetes authentication and authorization providers, enables authorization decisions for users based on Kubernetes RBAC checks against Perses CRDs. This change marks a forward step in Perses Kubernetes integration story, allowing Perses CRDs to not just create resources but be used in conjunction with Kubernetes Roles and RoleBindings to provide access checks for users within Perses itself. Due to the variety of authentication providers for Kubernetes, the implementation is designed to be provider agnostic. When enabled, Perses expects requests to contain an Authorization header in the form of Authorization: Bearer XXXX. The token is used to authenticate against the Kubernetes API Server and check if the user has permission to requested namespaces and resources.

The concept of authorization providers has been added with this change, marking the .security.authorization.guest_permissions and .security.authorization.check_latest_update_interval fields as deprecated, moving them to the "native" authorization provider. These fields will be removed in a future release.

security:
  authorization:
    provider:
      native:
        enable: true
        check_latest_update_interval: 5m
        guest_permissions:
        # ...

The frontend and percli have been updated to support these new providers. An /api/v1/user/whoami endpoint has been created to return user information for a logged in user. The percli has had --kube and --kubeconfig-file flags added which use the bearer token present in a kubeconfig file to authenticate with the Perses backend.

percli login --kube --kubeconfig-file="./kubeconfig" http://localhost:8080
successfully logged in http://localhost:8080

The Kubernetes authentication and authorization providers must be enabled together. When enabled, the Perses backend will use its pod's service account to authenticate and authorize users. The service account should be given TokenReview and SubjectAccessReview create and Namespace list permissions. The authenticator and authorizer provider configurations are exposed as configuration options:

security:
  enable_auth: true
  authorization:
    provider:
      kubernetes:
        enable: true
        qps: 500
        burst: 1000
        authorizer_allow_ttl: 5m
        authorizer_deny_ttl: 30s
        authenticator_ttl: 2m
  authentication:
    providers:
      kubernetes:
        enable: true

CLI improvements

• plugin test-schemas has been improved to test that the actual migrated schemas are valid against the expected schemas.
• plugin start is now able to discover the port used by rspack to serve the plugin in development mode, so you don't need to provide it anymore.
  • There was also an issue when loading a plugin in development with no schema defined, it is now fixed.
  • When stoping the command, there was some orphan process left, it is now fixed.
  • As mentioned before, the CLI has been updated to be compatible with the new dev plugin API introduced in this release.
• lint: when you were using local plugin to validate the dashboards, it was mandatory to have the plugins extracted in a folder. Now you can also provide the plugins as an archive like it is the case for the Perses server. The command will extract the plugins before starting validating any data.

Plugin improvements

// TODO list of improvements, ideally give major changes and improvements for each plugin.

GO-SDK Change in the way to define a query plugin

In the previous version of the GO-SDK, a query plugin was defined by using the Query builder. The issue with this approach is that it was not possible to provide the high level query type as it was hardcoded in the query builder.

This was not a problem for the Perses app as we only have one query type until recently. It changed with the introduction of the new query types: "ProfileQuery", "LogQuery" and "TraceQuery". To support this new use-case, we had to introduce a breaking change in the way to define a query plugin.

Now, instead of using the Query builder, you need to fill a struct query.Option that contains the query plugin and the high level query type.

If we take the Prometheus plugin as an example, the implementation will change from this:

package query

import (
	"github.com/perses/perses/go-sdk/query"
)

func PromQL(expr string, options ...Option) query.Option {
	return func(builder *query.Builder) error {
		plugin, err := create(expr, options...)
		if err != nil {
			return err
		}

		builder.Spec.Plugin.Kind = PluginKind
		builder.Spec.Plugin.Spec = plugin
		return nil
	}
}

to this:

package query

import (
	"github.com/perses/perses/go-sdk/query"
	"github.com/perses/perses/pkg/model/api/v1/common"
	"github.com/perses/perses/pkg/model/api/v1/plugin"
)

func PromQL(expr string, options ...Option) query.Option {
	plg, err := create(expr, options...)
	return query.Option{
		Kind: plugin.KindTimeSeriesQuery,
		Plugin: common.Plugin{
			Kind: PluginKind,
			Spec: plg,
		},
		Error: err,
	}
}

Support of temperature units

Celsius (°C) and Fahrenheit (°F) temperature units are now available for panel plugins that support unit configuration.

Introducing VictoriaLogs and ClickHouse as new data-sources

On top of that, this release is also introducing two new data-sources: VictoriaLogs and ClickHouse provided directly by the community.

// TODO: write more about these two data-sources, highlight their features, and who did it.

Note that since these two data-sources are provided by the community, they are not officially supported by the Perses team. And as such, soon we will come with a governance model to manage community plugins. In later release, these plugins might be removed in the main images, depending on the governance adopted. You will still be able to use them by installing the datasources in your Perses instance.

This update expands Perses' observability capabilities by introducing support for logging and continuous profiling, along with new plugins for Pyroscope, Flame Chart, Loki, and log visualization.

Additional enhancements include a heatmap panel for Prometheus histograms, a quick query viewer, panel group variable repeat, usability improvements, and upgraded CLI commands to streamline plugin development and schema testing.

New profiling plugins

This release provides the support of Continuous Profiling through two plugins:

• Pyroscope: a datasource plugin for retrieving and handling data from a Pyroscope server.
• Flame Chart: a visualization plugin which contains 3 panels: Flame Graph, Table View and Series Chart.

What is Continuous Profiling?

Continuous Profiling is a new observability signal, complementing the traditional logs, metrics, and traces. This innovative approach provides a way of continuously measuring applications' resource consumption with code-level granularity and low overhead. This signal generates excitement in the community for its ability to provide in-depth visibility into production performance of applications.

Panels

Flame Graph

The flame graph panel offers a simple and intuitive way to represent performance data, providing a hierarchical view that let you zoom in on any stack for a detailed analysis. It helps to understand resource allocations (CPU, Memory, ...) and bottlenecks within an application.

Table View

This panel displays the profile in a table format. It allows you to sort stacks, for example in descending order, to see which function consume the most resources. A search bar is also present for filtering the table and highlighting stacks in the flame graph.

Series Chart

When retrieving profiles from the Pyroscope server, they include timeline data showing how the total amount of resources consumed evolves over time, depending on the selected profile type. This panel allows you to visualize this data in order to identify spikes in resource consumption (CPU, memory, etc.) and focus on them by zooming into the corresponding time range.

New Logs plugins

This release introduces two new plugins enabling log visualization and exploration in Perses:

• Loki: a datasource plugin for retrieving and handling data from a Loki server.
• Logs Panel: a visualization plugin for displaying and exploring logs.

These new plugins have been developed by the Perses community. A big thank you to @abelyakin !!

Heatmap

As spoiled on the previous release note, the heatmap panel has been added on Perses! It is now possible to visualize Prometheus native histograms in a heatmap format. This panel is particularly useful for visualizing latency distributions over time.

This panel still need to be improved, so stay tuned for future updates! Or even better, contribute to it! List of improvements to be done can be found in the GitHub issue #2978

Quick Query Viewer

Panels introduces a new feature called Quick Query Viewer using which users can quickly check the executed queries without being in edit mode. The feature has added a new, default icon button into the panel header. When clicked a modal is opened in which you can see relevant query specs.

Panel group repeat

Panel group now support variable repeat. This allows you to create a panel group and have it repeated for each value of a variable.

You can define the repeat variable in the panel group settings dialog. It will be also applied to preview in panel group. When editing a panel inside a panel group with repeat, changes will be applied to all panels group repeated.

User profile

We are introducing user profiles in Perses!

For the moment, the user profile page only contains the list of the permissions associated to the account used. But it is the first step towards a more complete user profile page, which will include more functionalities in the future.

Discard changes prompt

When editing a dashboard, if you try to leave the page with unsaved changes, a prompt will appear to warn you about potential lost changes. There are 2 different prompts depending on how you try to leave the page:

• If you try to navigate to another page in Perses, a modal will appear to confirm you want to leave the page.
• If you try to close the tab or navigate to another website, a browser native prompt will appear.

Explorer improvements

Explorer can now show more information about your resources, thanks to collapsable tab menu!

Few other improvements have been made to the explorer, such as:

• Tabs are now sorted alphabetically
• The metric finder datasource selector is rendered correctly
• Metric finder filter inputs are now displayed in 3 parts: key, operator, value. Instead of a single input.

Plugins Improvements

Traces

Attribute Search

The Tempo plugin now allows you to search for traces by attributes directly in the query editor, without writing a TraceQL query manually.

Span Links

You can now view span links in a new Links tab when clicking on a span which has links configured. This makes it easier to explore related spans and understand trace relationships.

Download Traces

The TracingGanttChart panel now includes a download action in the panel header. With one click, you can export the entire trace in OTLP/JSON format for offline analysis or sharing.

Linking Improvements

The TracingGanttChart, TraceTable, and ScatterChart panels now support configuring links in the panel spec. You can configure the link to a specific trace (e.g. relevant for the trace table) or create dynamic links from resource and span attributes (in the TracingGanttChart panel).

CLI Improvements

New command percli plugin test-schema

This new command provides a way to test the Cuelang schema and the migration schema. Here how it works:

First, all tests files needs to be placed directly alongside the schema file to test, within a tests folder. Then you will have different way to test the schemas:

Tests validating the model:

• Validate that a JSON file is accepted by the plugin's CUE schema.
• Place valid tests under "tests/valid/". "tests" is located next to the entrypoint of the "model" CUE package.
• Each test is a JSON file containing a valid configuration expected to pass validation.

Tests verifying invalid possibility:

• Validate that a JSON file is rejected by the plugin's CUE schema.
• Place invalid tests in "tests/invalid/". "tests" is located next to the entrypoint of the "model" CUE package.
• Each test is a JSON file containing an invalid configuration expected to fail validation.

Migration Tests:

• Validate migration logic defined in the plugin's "migrate.cue" file.
• Place migration tests under "migrate/tests/". "tests" is located next to "migrate.cue".
• Each test is a directory containing:
  • "input.json": The source file (e.g., Grafana format).
  • "expected.json": The expected result after migration (Perses format).
• The migration test unifies the input with the migration schema and compares the result to the expected output.

Example of file structure for a single plugin:

schemas/
├── model.cue
├── tests/
│   ├── valid/
│   │   ├── basic-config.json
│   │   └── advanced-config.json
│   └── invalid/
│       ├── missing-required.json
│       └── invalid-type.json
└── migrate/
├── migrate.cue
└── tests/
├── basic-migration/
│   ├── input.json
│   └── expected.json
└── complex-migration/
├── input.json
└── expected.json

More complex example for a package embedding several plugins:

schemas/
├── my-datasource/
│   ├── model.cue
│   ├── tests/
│   │   ├── valid/
│   │   │   ├── basic-config.json
│   │   │   └── advanced-config.json
│   │   └── invalid/
│   │       ├── missing-required.json
│   │       └── invalid-type.json
│   └── migrate/
│       ├── migrate.cue
│       └── tests/
│           ├── basic-migration/
│           │   ├── input.json
│           │   └── expected.json
│           └── complex-migration/
│               ├── input.json
│               └── expected.json
└── my-query/
├── model.cue
├── tests/
│   ├── valid/
│   └── invalid/
└── migrate/
├── migrate.cue
└── tests/`,

Improvement of the command percli plugin start

This command has been improved to provide a better experience when starting a plugin locally.

Note: all improvement described below will only work with a remote server of version >= 0.52.0 as it also included new endpoints to make the features work.

1. With this new version, the command is now able to detect any changes on the Cuelang schema. When a change is detected, the command will trigger the remote server to reload the schema internally. This improvement is particularly useful during the development of a plugin, as it allows to see the changes of the schema immediately without having to manually restart the server and the plugin watching process.

2. When stopping the command, it will now unregister any plugin it was watching. This is useful to avoid having to restart the remote server to get back the list of registered plugins clean. It also solve an issue about being able to override a plugin with the development version of the same plugin.

With the Perses MCP Server, users can use AI Agents to understand, query and interact with Perses APIs in a standardized and secure manner.

Imagine being able to prompt your favorite AI Agent with questions like:

• "How many dashboards are created in the last 5 days in project 'Test Project'?"
• "What is the default datasource for project 'Test Project'?"
  • "Is this datasource in proxy mode? and what is the URL?"
• "Analyze this dashboard 'Dashboard A' in project 'Test Project'"
  • Suggest me some improvements to panels and PromQL queries in this dashboard

As you can see, the possibilities are endless. The Perses MCP Server allows you to interact with Perses in ways that were previously not possible.

This diagram visually represents how the Perses MCP Server acts as an intermediary between your AI Agent and the Perses Application.

What is MCP - The Model Context Protocol Explained

You might be wondering what makes this all possible. The magic behind the scenes is the Model Context Protocol (MCP), an open standard pioneered by Anthropic that is quickly gaining industry-wide adoption.

MCP’s purpose is to create a universal language for AI agents to interact with the "outside world" that is, any data or system beyond their initial training data. This protocol enables AI to securely access real-time information and perform tasks by connecting to external APIs. In short, MCP provides a paved road for Large Language Models (LLMs) to interact with external systems like databases, APIs, and filesystems.

Major players like Google, Microsoft, and OpenAI have already committed to supporting MCP.

How to Use the Perses MCP Server

Using the Perses MCP Server is simple and straightforward.

1. Follow this User Guide to install and configure the MCP Server;
2. Ask a Question: Pose a natural language question to your favorite AI agent, such as, "When was 'Dashboard A' in 'Project B' last updated?";
3. Get an Answer: The MCP Server instantly gets to work, querying the Perses API and delivering the answer back to your AI agent in seconds.

Check out this short demo to see it in action:

Getting Started with Perses MCP Server

Ready to dive in? Here are the resources you'll need:

• Perses MCP Server GitHub Repository: Explore the code, read the documentation, and find the installation instructions here;
• Perses Official Website: Discover more about the Perses, its features, blog posts and documentation here.

What's next?

This public beta is just the beginning. Currently, the server supports read-only operations, allowing you to query the Perses API. Our roadmap includes adding write capabilities, which will enable you to use AI agents to create and update Perses resources like dashboards, projects, and datasources.

We are committed to an open development process and we welcome your feedback and contributions as we build these new features.

Every CNCF User/Developer/Contributor has, at some point, to endure the frustration of trying to salvage an outdated dashboard, or adapting upstream YAML, only to get to the point of wondering why it doesn't work on their setup. This leads to a recurring pattern: everyone ends up rebuilding the same dashboards, over and over again, each slightly different.

The Mixins Dashboards helped bring about a sense of relief, as users now could use dashboards and alerts packaged together with the code they are deployed with. In theory, this promised consistency and easier integration. In practical terms, as the concept of mixins relies on Jsonnet, and even though it’s a suitable language for configuration management, it leads to a few issues:

• Jsonnet has a steep learning curve. It’s not a conventional Turing-complete programming language, and often makes it hard for downstream users of mixins to be able to do any sort of customization on their dashboards;

• Mixin Jsonnet is completely detached from the actual application code. It was introduced as a way to maintain dashboarding config for code that you are deploying side by side, to ensure it never goes out of sync. However, many mixins are rarely updated, even when the code is - sometimes these are maintained out of the tree. And Jsonnet cannot use Go structs, so there is no automatic validation during code changes. Thus keeping mixins accurate and reliable demands a lot of effort.;

• Adoption has also been uneven. A good example of this is kube-prometheus stack, built with Jsonnet, where many users bypass it entirely and only fetch the rendered YAML from that repository, then doing any sort of changes with tools like Kustomize instead. This undermines the original goal of reuse and standardization.

The end result is, that despite the promise of reusable dashboards, the reality is there’s still not a widely used solution for automatic dashboards creation.

Perses KubeCon EU Recap - Maybe there’s a better way to build Dashboards

During KubeCon EU 2025 in London, two of Perses’ core maintainers, Nicolas Takashi and Antoine Thébaud, shared how Perses is changing the way engineers develop and manage dashboards as code. Their talk covered the power of the Open Dashboard Model, how to use strongly typed code with the Perses Go SDK, and why this approach fits naturally into CI/CD pipelines using modern GitOps practices. If you didn’t get a chance to watch it live, you can watch the full session here.

They also mentioned the Community Dashboards Project, but didn’t have time to dive into it during the session. With that in mind is our belief that such an important topic deserves more space, and as so we bring this into live here.

Moving away from rebuilding the same dashboards to composable dashboards

With the limitations of mixins in mind, the Perses community decided to take a different path. Since Perses is written in Go, with both its configuration and plugins defined using Go structs, it presents an opportunity to design dashboards in a more efficient and structured way. This approach takes full advantage of the Go structs imported from Perses, with its robust SDK that has the methods and constructs to build dashboards. This then ensures consistency with the core project, safe versioning, both for the dashboard data model and each individual panel plugins, and type-safe dashboard construction and customization.

Introducing the community-dashboards repository. Maintained by community contributors, it offers the following dashboards in type-safe modular Go SDK based Dashboards as Code:

The goal of the community-dashboards library isn't just to provide ready-to-use YAML dashboards (though you can use them as-is), but to empower users to import the project as a Go module in their downstream configuration, generate tailored subsets of dashboards, and customize or extend them to meet specific needs (similar to what mixins originally intended).

A core strength of the Perses Community Dashboards is its modular, reusable panel library. These panels—such as Go CPU Usage and Memory Consumption—serve as building blocks that can be composed into new dashboards. Instead of starting from scratch, users can leverage these community-maintained components to quickly build dashboards suited to their applications and workloads.

This approach also lowers the barrier to achieving consistency across dashboards. By reusing the same patterns to build and display common metrics, dashboards remain aligned across teams and services. This makes it easier to compare environments, onboard new engineers, and scale observability practices—without reinventing the wheel.

How to build composable dashboards - a practical example

Here we have an example of how to define a panel of Time Series type below. More detailed info about the available option for Time Series Panels can be found here and PromQLBuilder.

// Define your panel
func CPUUsage(datasourceName string, labelMatchers ...*labels.Matcher) panelgroup.Option {
	return panelgroup.AddPanel("CPU Usage",
		panel.Description("Shows the CPU usage of the component."),
		timeSeriesPanel.Chart(
			timeSeriesPanel.WithYAxis(timeSeriesPanel.YAxis{
				Format: &commonSdk.Format{
					Unit: string(commonSdk.DecimalUnit),
				},
			}),
			timeSeriesPanel.WithLegend(timeSeriesPanel.Legend{
				Position: timeSeriesPanel.BottomPosition,
				Mode:     timeSeriesPanel.TableMode,
				Values:   []commonSdk.Calculation{commonSdk.LastCalculation},
			}),
			timeSeriesPanel.WithVisual(timeSeriesPanel.Visual{
				Display:      timeSeriesPanel.LineDisplay,
				ConnectNulls: false,
				LineWidth:    0.25,
				AreaOpacity:  0.5,
				Palette:      timeSeriesPanel.Palette{Mode: timeSeriesPanel.AutoMode},
			}),
		),
		panel.AddQuery(
			query.PromQL(
				promql.SetLabelMatchersV2(
					promqlbuilder.Rate(
						matrix.New(
							vector.New(
								vector.WithMetricName("process_cpu_seconds_total"),
							),
							matrix.WithRangeAsVariable("$__rate_interval"),
						),
					),
					labelMatchers,
				).Pretty(0),
				dashboards.AddQueryDataSource(datasourceName),
				query.SeriesNameFormat("{{pod}}"),
			),
		),
	)
}

Next after you have your first panel, it’s time to add it to a dashboard - here’s how to add to a dashboard named Workload / Overview:

// Use the panel in a dashboard
func withResources(datasource string, clusterLabelMatcher *labels.Matcher) dashboard.Option {
	labelMatchersToUse := []*labels.Matcher{
		promql.JobVarV2,
	}
	labelMatchersToUse = append(labelMatchersToUse, clusterLabelMatcher)

	return dashboard.AddPanelGroup("CPU Usage",
		panelgroup.PanelsPerLine(1),
		panelgroup.PanelHeight(10),
		panelsGostats.CPUUsage(datasource, labelMatchersToUse...),
	)
}

// Build the dashboard and add the time series panel withResources
func BuildWorkloadOverview(project string, datasource string, clusterLabelName string) dashboards.DashboardResult {
	clusterLabelMatcher := dashboards.GetClusterLabelMatcherV2(clusterLabelName)
	return dashboards.NewDashboardResult(
		dashboard.New("workload-overview",
			dashboard.ProjectName(project),
			dashboard.Name("Workload / Overview"),
			dashboard.AddVariable("job",
				listvariable.List(
					labelvalues.PrometheusLabelValues("job",
						labelvalues.Matchers("workload_build_info{}"),
						dashboards.AddVariableDatasource(datasource),
					),
					listvariable.DisplayName("job"),
				),
			),
			withResources(datasource, clusterLabelMatcher),
		),
	).Component("workload")
}

For more on the SDK please check perses/go-sdk, and community-dashboards.

Beyond Copy-Pasting - Cleaner and Smarter way to building Dashboards

Going back to the idea of copy-pasting raw YAML or JSON, although it might seem quicker, it leads to painful maintenance over time. The Go SDK offers a better path:

• Type safety - You get compile-time feedback if something is wrong. No more mystery errors buried in JSON blobs.
• Reusability - Define a panel once and reuse it wherever you want. Avoid duplication and drift.
• Maintainability - When a panel definition needs an update, you can do it in one place and apply it across all dashboards.
• CI/CD friendly - Code is easier to version, review, and test. It fits naturally into modern GitOps workflows.

Combining the use of panel libraries and the SDK, you get a flexible and scalable way to manage dashboards, while saving time, reducing errors, and staying consistent across your observability stack. This allows a community of dashboards users to have their lives made easier with these features.

Also considering the most commonly used dashboard across platforms and teams, like Kubernetes, Prometheus and exporters like Node Exporter, Blackbox Exporter, also projects like Thanos dashboards as it tends to be a power duo within the Prometheus ecosystem, we have from the get go some core dashboards that will help you in the long term in your observability journey.

Next Steps for the Community Dashboards

We’re committed to expanding support for more CNCF and other OSS projects while continuing to enhance the existing panel libraries. By adding more features and improving the quality of reusable panels, we enable users to gain deeper insights from their dashboards because the faster you can pinpoint an issue in your telemetry data, the better.

Also, we aim to ensure proper documentation for all dashboards. Whether you're importing full dashboards or using panel libraries as building blocks, we want to make the process as seamless as possible. That means clear, well-commented code and guidance, so modularity is not only guaranteed but also easy to work with, without needing to dig through the entire codebase.

Ultimately, this is a community effort, and we invite everyone to help grow this project. So if you have a dashboard you’ve rewritten more than once, or any mixin dashboard you use, but want to ensure it becomes modular, easily used and want to increase adoption of it. Whether it’s opening an issue or submitting a contribution, all help is moving forward so we can all, very soon, stop rebuilding the same dashboards.

Let’s stop duplicating efforts and start building shared observability standards!

This release brings several new features, improvements, and bug fixes to enhance your experience with Perses.

It is a significant step forward in the evolution of Perses, and we are thrilled to share it with you. We have been working hard to bring you a more powerful and flexible platform for your observability needs.

This release includes a new plugin architecture, new panel, new variable, a new repository perses/plugins containing all default plugins supported by Perses.

We have also made significant improvements to the documentation, highlighting features that were implemented some time ago but not well advertised, such as datasource discovery and ephemeral dashboards.

New Plugins system

Big news from us at Perses! We've rolled out a brand-new plugin system, and it's all about making things more flexible and expandable. Our goal? To provide a more flexible and extensible way to scaffold, develop and distribute plugins in Perses so we can expand the possibilities for sources of data, visualization and interactions within the platform.

What's Under the Hood?

Leveraging module federation plugins can now operate independently of the main Perses code. Opening up a world of possibilities for developers to create and share plugins without being tied down to the core codebase. Plugins can be grouped into Plugin Modules, which are essentially collections of related plugins that can be developed and distributed together. Underneath it all, the system has a backend that handles data validation and migrations using Cuelang schemas, and a frontend that brings everything to life with React components.

Easier Plugin Development

To make life easier for developers, we've built some handy plugin commands right into our command-line interface, percli. The CLI will do all the heavy lifting from setting up your project, getting your development environment ready, to building your plugins. That way, you can kick back and focus on the exciting part: actually creating awesome plugin features!

How Does It Work?

The new plugin system is designed to be super user-friendly. You can scaffold a plugin using the percli plugin generate command, which will set up the new plugin files for you. This command can be used several times to create multiple plugins in the same plugin module. Then you can start developing your plugin using percli plugin start to run it in development mode and test it out in your local Perses instance. Finally, compile it with percli plugin build to prepare it for distribution.

You can follow the documentation for details and examples to get started with creating your own plugins.

Where to Find Plugins

Thanks to this new setup, our main Perses plugins have moved to their own dedicated home at perses/plugins. And speaking of plugins, the system supports a bunch of different types:

• Datasource: Perfect for grabbing data from all sorts of places.
• Query: This one links your datasources to your panels.
• Panel: Your go-to for making data look good through various visualizations.
• Variable: For when you need dynamic values in your queries.
• Explore: A special kind of panel designed for diving deep into your data.

You just use percli to get started, test your creations, and then build them up to distribute as archive files or npm packages. After that, they're ready to be installed on a Perses server or even embedded directly into other React apps.

So, what kind of plugin are you dreaming of building first?

Which plugins are available in Perses

All plugins that are available in the repository perses/plugins are installed by default in Perses.

You can find the list of available plugins at runtime in the UI, in the Configuration page, under the Plugins tab.

You can also use the CLI command percli plugin list to get the list of available plugins.

percli plugin list

        NAME        │   VERSION   │     TYPE     │ LOADED │ FROM DEV
────────────────────┼─────────────┼──────────────┼────────┼──────────
 DatasourceVariable │ 0.1.2       │ Variable     │ true   │ false
 GaugeChart         │ 0.7.1       │ Panel        │ true   │ false
 Markdown           │ 0.7.1       │ Panel        │ true   │ false
 Prometheus         │ 0.51.0-rc.1 │ PluginModule │ true   │ false
 ScatterChart       │ 0.6.1       │ Panel        │ true   │ false
 StaticListVariable │ 0.3.1       │ Variable     │ true   │ false
 Table              │ 0.6.1       │ Panel        │ true   │ false
 HistogramChart     │ 0.7.2       │ Panel        │ true   │ false
 PieChart           │ 0.7.1       │ Panel        │ true   │ false
 TimeSeriesChart    │ 0.8.0       │ Panel        │ true   │ false
 TimeSeriesTable    │ 0.7.1       │ Panel        │ true   │ false
 TraceTable         │ 0.6.1       │ Panel        │ true   │ false
 BarChart           │ 0.7.1       │ Panel        │ true   │ false
 TracingGanttChart  │ 0.6.1       │ Panel        │ true   │ false
 StatChart          │ 0.7.1       │ Panel        │ true   │ false
 StatusHistoryChart │ 0.7.2       │ Panel        │ true   │ false
 Tempo              │ 0.51.0-rc.1 │ PluginModule │ true   │ false

New Plugins

Datasource variable

Thanks to the community contributions, we are introducing a new plugin: the Datasource Variable. This plugin allows the possibility to use a datasource as a variable in your dashboard, specially in the queries of your panels.

This is particularly useful when you have multiple datasources of the same type, such as multiple Prometheus instances, and you would like to switch between them without having to modify each panel query.

Of course, this plugin is not limited to Prometheus; it can be used with any datasource.

Note: If you are familiar with Grafana this feature wont will feel particularly new to you. It's a valuable addition to Perses, helping to bring feature parity and making it a strong alternative for those considering or exploring a transition.

Histogram Chart

This release introduces a new plugin: the Histogram Chart. This plugin allows you to visualize Prometheus Native Histograms, providing a clear and concise way to understand the distribution of your histogram buckets.

This panel is supporting thresholds, which allow you to colorize the chart based on specific values, making it easier to understand your data.

This chart is also used in TimeSeriesTable panel to display histogram details, allowing the Explore page to display histograms.

In next releases, we are planning to add exponential mode support, add support for Prometheus classic histograms and summaries and thresholds on bucket counts. Feel free to give us ideas on how to improve this plugin, with issues or discussions on the Perses GitHub repository. Spoiler: the heatmap panel is coming next release 🤫

Breaking Change in Dashboard as Code

As previously mentioned, we have relocated the default plugins to a new repository. This includes not only the frontend code, which has been transferred there, but also the corresponding Go SDK and CUE SDK for each plugin.

This move is a breaking change for the Dashboard as Code feature as when upgraded to the last version, you will no longer have the plugin code from perses/perses repository.

All imports will have to be updated to point to the new repository. We created a module for each plugin so you can import only the ones you need.

For example, in Go SDK, in case you are using the plugin label-values from the Prometheus module, you will need to go get the plugin first:

go get github.com/perses/plugins/prometheus

Then, in your Go code, you will have to change the import path from:

import labelValuesVar "github.com/perses/perses/go-sdk/prometheus/variable/label-values"

to:

import labelValuesVar "github.com/perses/plugins/prometheus/sdk/go/variable/label-values"

As a complete example, this PR: https://github.com/perses/community-dashboards/pull/69 is demonstrating the required changes you will have to do in your code when upgrading to the v0.51.0 of Perses.

In the case of CUE SDK, we are also leveraging on the new dependency management introduced by CUE v0.12.0. Where we previously had a custom-made schema retrieval achieved by percli dac setup, Perses is now fully aligned with the new CUE modules.

To continue using the CUE SDK, you will need to update your CUE files to import the new modules, but also to upgrade the cue version you are using to at least v0.12.0.

Custom Lint rules

As you may know, to validate your dashboard, we have implemented a set of rules. These rules are executed when you save your dashboard during the unmarshalling step from JSON or YAML or during the validation of each plugin using Cuelang.

In this release, we have added the ability to create custom lint rules. This allows you to enforce specific standards or practices within your organization.

These custom rules should be defined in the configuration file of your Perses instance, typically located at /etc/perses/config.yaml. The rules are defined under the dashboard.custom_lint_rules section.

Here is an example of how to define custom lint rules for dashboards:

dashboard:
  custom_lint_rules:
    - name: "Dashboard Naming Convention"
      target: "$.metadata.name"
      assertion: "value.matches('^[a-z]+(-[a-z]+)*$')"
      message: "Dashboard name must be all lowercase letters with hyphens only."
      disable: false

    - name: "At Least One Panel Exists"
      target: "$.spec.panels"
      assertion: "value.size() > 0"
      message: "Dashboard must contain at least one panel."
      disable: false

We are using the JSONPath syntax to target specific parts of the dashboard JSON structure, and the assertion is a CEL expression.

To know more about the syntax of the rules, please refer to the documentation

Disable datasource and variable

In Perses, it is possible to create datasource and variables at three different levels: global, project, and dashboard.

Usually, for security and governance reasons, you may want to prevent people to create datasource and variables at various levels. For global and project levels, this is already possible using the RBAC system.

But before this release, it was not possible to disable the creation of datasource and variables at the dashboard level.

In this release, we are introducing the ability to disable the manipulation of datasources and variables at any level. For that, you need to modify the configuration file of your Perses instance, and add the following section:

datasource:
  global:
    disable: true
  project:
    disable: true
  disable_local: true

This configuration is preventing the usage of datasources at any level and disable the associated HTTP route in the Perses proxy.

Of course, this config is silly because without datasources, you cannot use dashboards, but it is a good example of how to disable datasources.

The same example applies for variables:

variable:
  global:
    disable: true
  project:
    disable: true
  disable_local: true

Improvement of the datasource discovery

One year ago, we introduced the datasource discovery feature, which allows you to automatically discover remote datasources from the Kubernetes API or from a generic HTTP endpoint. And so far we never got feedback about it until a couple of months ago when SAP started using it.

Overview

We didn't have the opportunity to highlight this feature, so here is a quick overview of how it works.

Datasource discovery is useful when you have a large number of datasources, and you don't want to manually register them in your application. Note that this feature can only be used when registering Global Datasources.

We are supporting two types of discovery:

• Kubernetes API: This allows you to discover datasources that are registered in the Kubernetes API, such as Prometheus, Loki, and others. You can configure the discovery by specifying the namespace where the datasources are located, the label selector to filter the datasources and the type of the discovery you would like to use: service, pod, endpoint.
• HTTP Endpoint: This allows you to discover datasources from a generic HTTP endpoint. You can configure the discovery by specifying the URL of the endpoint. The endpoint should return a JSON array of Global Datasource.

If you want to learn more about this feature, please refer to the documentation.

Improvements

• We made a mistake about how the label selector was converted from the configuration file to the Kubernetes API. The label selector was not correctly formatted, which prevented the discovery from working properly.
• When converting a service to a global datasource, there was a corner case where the global datasource was not correctly created. And then Perses was not able to load the datasource.

Thanks to these little improvements, the datasource discovery feature is now more reliable and easier to use.

Community Dashboards

Fresh off our talk at KubeCon EU 2025 in London - Limitless Possibilities, Consistent Design: Crafting Dashboards With Perses DAC, given by two perses maintainers, Nicolas Takashi and Antoine Thébaud, we are happy to introduce the community-dashboards repository.

Here we provide support for commonly used Mixin Dashboards, like Prometheus, Kubernetes and Thanos, build on top of Dashboard as Code capabilities provided by Perses. We’ll dive deeper into the community-dashboards in our upcoming blog post, but starting today, you can begin using them right away — whether by:

• Importing them directly into your Perses instance;

• Using them as a starting point to build your own dashboards;

• Or reusing individual panels in your own dashboards-as-code workflows.

We're also welcoming the community to help us support and extent the community-dashboards. So if there are additional dashboards you’d like to see supported, feel free to reach out to the team - or even better, help us extend the supported dashboards with feedback or improvements to the dashboards. Your input helps shape what comes next!

Support OAuth2 authentication for Datasource

Another cool contribution from the community is the support for OAuth2 authentication for datasources.

Before this release, the only way to authenticate to a datasource was to use a token, basic authentication and/or TLS configuration (like client certificate).

But in real world scenarios, you may want to use OAuth2 authentication to access your datasources and this is now possible!

Support YAML and YAML K8s Custom Resource format for Dashboard

Finally, but not least, we are introducing the support for YAML and YAML K8s Custom Resource format when exporting a dashboard from the UI.

The YAML CR format is directly compatible with the perses-operator and can be used in your GitOps workflow.

In future releases, we will also support the YAML format for all other resources, so you can export a panel or variable in a YAML format.

See the complete release note for more details: v0.50.0

Migration

One of the greatest contents of this release is the migration that has been drastically improved.

Since the beginning of the project, we have been willing to provide an easy way to migrate dashboards from Grafana to Perses. As a reminder, you can migrate a Grafana dashboard using the HTTP endpoint /api/migrate or the UI or the CLI that consumes this endpoint.

The big issue with this feature was the memory leak that was hidden and not that easy to trigger. (See issue #2039)

This was a big blocker for the migration and one of the main reasons why Amadeus was not able to migrate to Perses. Amadeus has a huge number of dashboards, and the memory leak was too important to be ignored. To give you an idea, the memory leak was about 40GB after migrating 3000 dashboards. (~ 3MB per dashboard)

As you may know, we are using Cuelang for the Perses plugin validation, and at first, we implemented a complete way to migrate using Cuelang only. The idea behind was to append every migration script (one for each panel, variable, queries) to the main one. Then the Grafana JSON was converted to a Cuelang value, and we were applying the migration script to this value.

With the v0.50.0, we are changing deeply and only internally the way it's working. It doesn't change anything for the user, but it's a huge improvement for the maintainability and the performance of the migration.

We have entirely rewritten the migration process. It is now using a hybrid system partially written in Golang and the rest in Cuelang when the plugins are involved. Thanks to this new system, the Cuelang files written to migrate the panels, the variables, and the queries can be validated and tested before the migration is applied.

Thanks to this change, we are happy to announce the memory leak has been fixed and the migration is now working perfectly. We performed the same mass migration, and it succeeded without causing OOMKill, as it requires much less memory than before. The graph below shows we didn't exceed 3GB of memory during the migration.

Finally, we’ve also addressed numerous updates to the migration process itself, incorporating fixes and enhancements to better cover use cases raised by the community - thank you for your contributions!

Status History panel

Thanks to Alexander Belyakin from the community, Perses is supporting a new Panel: the Status History Panel.

The Status History panel provides a visual representation of the status of various metrics over time. It allows users to track changes in the status of different metrics, making it easier to identify patterns, trends, and anomalies. This panel is particularly useful for monitoring the health and performance of systems, as it can display status changes in a clear and concise manner. The panel can be customized to show different statuses, such as up, down, warning, or any other user-defined states, and it supports various visualization options to enhance the readability of the data.

And of course, this panel is fully compatible with the migration process.

General Improvements

UI

We have finally added the redirection to the initial URL after you are authenticated. This was definitely a missing feature annoying for the users.

This release also introduces various improvements to the Table Panel, such as debounced text fields in the editor, default column sorting, custom column ordering, default column width setting, and cell focus on hover.

CLI

First, we have fixed the login command not working if you were using the CLI to log in to different Perses servers.

Then, based on the community feedback, we also have improved the DAC (Dashboard as Code) sub-command. We hope the experience with our DAC framework will be better.

We are also introducing new commands for plugin development. That's something that comes along with the new plugin architecture we are working on since last year. These commands cannot be used currently as we are still working on the plugin architecture.

But stay tuned as we are really close to finishing this intense work! V0.51.0 is going to be incredible with a lot of changes!