# Pyrra for Prometheus SLOs on Kubernetes and Docker

> Pyrra turns service level objective definitions into Prometheus recording rules, burn-rate alerts, and an interface for reviewing error budgets. It fits teams that already use Prometheus but do not want to maintain SLO calculations by hand.

**pyrra-dev/pyrra** — Making SLOs with Prometheus manageable, accessible, and easy to use for everyone!

- Repository: https://github.com/pyrra-dev/pyrra
- Website: https://demo.pyrra.dev
- Stars: 1,569 · Forks: 153
- Language: Go
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/pyrra-dev-pyrra

## Pyrra's SLO scope and operator model

Pyrra addresses the gap between having time-series metrics and operating service level objectives consistently. It is intended for engineers who already collect Prometheus data but need a repeatable way to define availability targets, calculate error-budget consumption, and inspect burn rates. The intended audience is not limited to Kubernetes users. The README identifies Kubernetes, Docker, and filesystem operation as supported modes, with a filesystem-oriented operator available for environments outside Kubernetes.

The project packages its UI, API, and backend behavior in one Go binary. Those roles normally run as separate deployments in Kubernetes: one starts with the `api` argument, while another starts with the `kubernetes` argument. The API serves SLO information to the UI. The backend watches for `ServiceLevelObjective` objects and translates them into Prometheus rules. This division is explicit in the repository layout and README, rather than being inferred from the project's monitoring focus.

Pyrra also offers a filesystem path for static YAML and includes examples for Docker Compose, Mimir, OpenShift, nginx, Parca, and gRPC query ranges. Those examples indicate several possible Prometheus-compatible environments, but the documentation excerpt does not define every command required to run each example. The live demo at `demo.pyrra.dev` is the documented way to inspect the interface without first deploying a cluster.

## From ServiceLevelObjective YAML to Prometheus recording rules

An SLO begins as a YAML object with an API version, target, evaluation window, indicator definition, and optional grouping labels. In the README example, `spec.target` is `"99"`, `spec.window` is `2w`, and a ratio indicator defines separate `errors` and `total` PromQL metrics. The selected series comes from `http_requests_total`, with server errors selected by `code=~"5.."` and grouping by `route`.

The backend does not make a separate time-series database and then present the UI. Its central job is rule generation. According to the README, each SLO produces Prometheus recording rules for increases and burn rates over windows including three minutes, fifteen minutes, thirty minutes, one hour, three hours, twelve hours, two days, and the SLO window itself. The recording-rule names retain a relationship to the original metric. Labels identify generated records when several SLOs use metrics that could otherwise overlap.

Pyrra also generates four multi-burn-rate alerts with different severities. The UI then reads Prometheus-derived data and presents the objective, availability, remaining error budget, historical burn rate, and the underlying RED metrics: requests, errors, and duration. Caching of Prometheus query results is listed as a feature, while Thanos mode disables partial responses and requests downsampling at five-minute and one-hour intervals. Exact caching policy and Thanos query behavior are not documented in the excerpt.

## Kubernetes deployment and first SLO rollout

The quickest documented first deployment uses the generated manifests in the repository. This approach assumes access to a Kubernetes cluster and the surrounding resources referenced by those examples. The README refers to the Kubernetes example as `examples/kubernetes`, although the commands below use the singular `example` path exactly as printed in its manifest instructions.

Apply the setup resources first, then the main manifests, and finally the example SLOs. The setup stage should establish the components required by the application, while the later stages install Pyrra and its example objectives.

```bash
kubectl apply --server-side -f ./example/kubernetes/manifests/setup
```

A successful server-side apply means the Kubernetes API server has accepted each manifest sent in the setup directory.

Apply the main deployment and its RBAC or configuration resources next.

```bash
kubectl apply --server-side -f ./example/kubernetes/manifests
```

The repository's generated manifests are the concrete installation artifact here. They should be inspected for image references, namespace choices, service settings, and Prometheus integration before being used in a production namespace.

Finally, apply the example service level objectives.

```bash
kubectl apply --server-side -f ./example/kubernetes/manifests/slos
```

After that, the `kubernetes` mode watches the API server for `ServiceLevelObjective` resources. It creates `PrometheusRule` objects for the Prometheus Operator to pick up. If Prometheus Operator is unavailable, the documented fallback is `--config-map-mode=true`, which writes each recording rule to a separate `ConfigMap`.

For admission validation, the README also documents a `manifests-webhook` example using cert-manager to self-sign an issuer and issue a certificate that allows the Kubernetes API server to contact Pyrra. That path adds moving parts and is a different deployment from the basic manifest rollout.

## Filesystem, Docker, and Helm operating boundaries

The repository supports more than cluster-native SLO objects. `filesystem.go` and the filesystem examples indicate that Pyrra can consume SLO definitions from static YAML, which suits local development, Docker Compose, or hosts that do not expose a Kubernetes API. The project also provides an `examples/docker-compose` directory and Dockerfiles for building and packaging the binary.

The runtime image follows a small container structure. Its final stage is Alpine 3.23.4, the Pyrra executable is copied to `/usr/bin/pyrra`, and the container runs as user `65533`. The Dockerfile uses `ENTRYPOINT ["/usr/bin/pyrra"]`, so mode-specific arguments are appended when the container starts.

For Kubernetes users, Pyrra also has an official Helm chart at the documented Artifact Hub package `pyrra-dev-helm-charts/pyrra`, with chart development maintained in the separate `pyrra-dev/helm-charts` repository. The README also states that Pyrra's Jsonnet code is imported by `kube-prometheus`. That offers a different distribution path from manually applying Pyrra's generated manifests.

This breadth matters operationally. A filesystem deployment avoids Kubernetes RBAC and CRD management, while a Kubernetes deployment gains API-server watching and native `PrometheusRule` output. It does not remove the need for valid Prometheus queries, access to the correct metrics, and a rule evaluation path.

## Prometheus Operator versus direct rule ownership

The practical alternative is to keep SLO calculations as manually maintained Prometheus rules and render their status with Prometheus and Grafana. In that approach, engineers write the recording and alert rules directly, configure their evaluation and labeling conventions, and manage dashboards separately. Pyrra instead accepts higher-level `ServiceLevelObjective` definitions and generates multiple burn-rate recording rules plus four multi-burn-rate alerts.

That abstraction changes the ownership boundary. With direct rules, rule changes are visible in the Prometheus configuration or generated `PrometheusRule` manifests. Pyrra introduces an operator that must detect SLO changes, update derived resources, and serve the API and UI. In Kubernetes mode with `--config-map-mode=true`, the output is split across `ConfigMap` resources instead of relying on `PrometheusRule` pickup by Prometheus Operator.

Pyrra's main benefit is consistency across repeated windows and alerts. Its limitation is that the YAML must still describe a meaningful metric relationship. If the numerator is not a subset of the denominator, or if grouping labels have incompatible series, generated calculations can be syntactically valid but operationally misleading. The README does not provide validation for every malformed or semantically inconsistent indicator.

For small installations with one or two stable SLOs, direct Prometheus rules may be simpler to inspect and change. Pyrra becomes more relevant when teams need a catalog, searchable labels, consistent burn-rate windows, an API, and a shared status view across many objectives.

## License, release cadence, and adoption constraints

Pyrra is distributed under Apache-2.0, as stated in the repository metadata. That identifies the project's declared license, but this review does not interpret license obligations or provide legal advice. Organizations still need to review dependencies, generated manifests, container bases, and their own distribution requirements separately.

The repository is not archived. Its last push was on 2026-10-14, two days before this review date. Releases include `v0.10.2` on 2026-09-18, `v0.10.1` on 2026-06-25, and `v0.10.0` on 2026-04-30. This is recent release activity, although the pre-1.0 version line can carry compatibility expectations that mature projects avoid. The README excerpt does not provide a migration guide or upgrade-compatibility matrix between these releases.

The Go module declares `go 1.26.0`, while the application includes a React or TypeScript UI build and Kubernetes controller dependencies. Teams building from source need the UI toolchain as well as Go and Kubernetes tooling. The Makefile separates UI preparation, static Go compilation, formatting, vetting, and generated manifests. Its `test` target runs `go test -race ./...` after generation and formatting steps, so adopting the repository's development workflow entails more than compiling the Go binary.

Pyrra should not be treated as a complete observability platform. It depends on Prometheus-compatible metrics and query access, and its alert generation expects the burn-rate model already described in the documentation. The first adoption check should therefore be whether one representative service can supply stable error and total series suitable for a ratio or latency indicator.

## Conclusion

Pyrra is a good fit for teams using Prometheus, especially Kubernetes teams managed by Prometheus Operator, that want declarative SLOs and an error-budget UI. It is a poor fit for environments without a dependable Prometheus metric model or organizations that require fully manual ownership of every generated rule. Before adoption, verify that the existing requests, errors, and duration metrics can satisfy the selected `ServiceLevelObjective`, then confirm whether rule resources must be emitted as `PrometheusRule` objects or per-rule `ConfigMap` objects. the decisive point is the `main` branch's recent release and push history, not an inferred production-readiness claim.

## FAQ

### What problem does Pyrra solve?

Pyrra manages service level objectives using Prometheus data. It converts YAML objectives into Prometheus recording rules, burn-rate alerts, and an API-backed interface for viewing objectives and error budgets.

### Does Pyrra support Kubernetes and Docker deployments?

Yes. Pyrra documents Kubernetes, Docker, and filesystem modes. In Kubernetes it watches `ServiceLevelObjective` resources, while filesystem operation reads SLO definitions from files.

### Does Pyrra require Prometheus Operator?

Not for every documented deployment. Kubernetes mode normally creates `PrometheusRule` objects for Prometheus Operator, while `--config-map-mode=true` saves each recording rule in a separate `ConfigMap` when that integration is unavailable.

### What license does Pyrra use?

The repository metadata identifies `Apache-2.0` as the license.

## Sources

- [License: Apache-2.0](https://github.com/pyrra-dev/pyrra/blob/main/LICENSE)
- [Project website](https://demo.pyrra.dev)
- [pyrra-dev/pyrra on GitHub](https://github.com/pyrra-dev/pyrra)
- [README](https://github.com/pyrra-dev/pyrra/blob/main/README.md)
- [Releases](https://github.com/pyrra-dev/pyrra/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pyrra-dev-pyrra