Platform overview · 2026

Govern telemetry before the observability backend.

Cerbi is a logging and telemetry governance platform for teams that need to answer four operational questions consistently: what may be emitted, which policy applies, where is that policy enforced, and what evidence proves the control was active?

The product model

Scan

Find risky telemetry and policy violations in source and CI before runtime.

Govern

Define profiles, targets, validation, deployment state, and policy history in CerbiShield.

Enforce

Apply policy in-process with CerbiStream, at the OTLP boundary with Gateway, or both.

Prove

Review violations, evidence, reporting, audit context, usage, and platform health.

This is deliberately not a rip-and-replace observability architecture. Cerbi governs telemetry before it reaches the platforms that already store, search, correlate, visualize, and alert on it.

Cerbi Scanner: discover risk before runtime

Scanner is the low-friction entry point. It can run against repositories and CI to find logging patterns and governance issues before a runtime component is introduced. That makes the first customer conversation concrete: use one repository, show the findings, and decide whether runtime enforcement is justified.

Explore Scanner

CerbiShield: control + evidence plane

CerbiShield manages the governance lifecycle around enforcement rather than acting as the raw-log destination. It is where teams author and validate policy, target workloads, deploy changes, inspect violations, review evidence, track audit context, report on posture, and operate the platform.

OverviewGovernance score, workload posture, violation trends, attention items, and platform state.

RulesTemplates, composer/editor workflows, compatibility checks, validation, and targeted deployment.

DeploymentsTargets, environments, rollout history, status, operator context, and deployment detail.

ViolationsSeverity and rule trends with workload drill-down and filterable violation exploration.

ValidationRepresentative payload testing before policy is promoted into a live enforcement path.

Evidence + reportingGovernance evidence, coverage and score trends, operational reporting, and export workflows.

AuditActor, resource, action, version, target, and timestamp context around governance changes.

HealthService health, latency, queue/database state, routing activity, error signals, and platform operations.

Dashboard tour

Two enforcement boundaries

CerbiStream

Inside the application

Use when governance should execute before the first network hop. This is the stronger boundary for selected high-risk applications and requires application integration.

Cerbi Gateway

On the OTLP path

Use when workloads already emit OpenTelemetry and platform teams need a central adoption path. No Cerbi SDK is required for those workloads; the existing observability destination remains downstream.

Gateway security and reliability

Customer-hosted Azure Container App

HTTPS OTLP/HTTP ingress restricted to a customer-approved CIDR

Required signed Runtime Policy Bundle verification

Customer-local non-exportable P-256 Key Vault signing key

Private customer-local runtime-policy storage

TLS downstream OTLP transport

Bounded memory, batch processing, queued export, and retries

Liveness/readiness probes and horizontal scaling

Gateway is currently a controlled preview / Marketplace release candidate. Cerbi does not publish a Gateway events-per-second number yet because the dedicated reproducible benchmark is still a release-quality evidence item, not a marketing placeholder.

Read Gateway technical brief

Who buys this and why

Platform engineeringAdopt one policy model across application and OTLP enforcement without replacing the existing observability estate.

Security engineeringReduce sensitive-data exposure and keep cryptographically verifiable runtime policy inside the customer trust boundary.

DevSecOpsMove checks into source and CI, validate before rollout, and preserve controlled deployment history.

Observability teamsGovern before indexing while preserving the tools, dashboards, alerts, and retention workflows already in place.

Risk / complianceUse bounded governance evidence and reporting to support control reviews without pretending a product install equals certification.

A practical adoption sequence

01Scan one repository and review the actual telemetry risks found.
02Define one governance profile that addresses a real customer requirement.
03Choose the enforcement boundary: CerbiStream for an application or Gateway for an OTLP workload.
04Run the change in non-production and validate representative telemetry.
05Review violations, deployment state, evidence, health, and measured overhead in CerbiShield.
06Expand only after the team can show the control works operationally.

Start with evidence, not a platform migration.

The fastest way to decide whether Cerbi belongs in an environment is to scan one codebase or route one representative OTLP workload through a bounded evaluation.

Talk through a pilot