Deploy the tenant-hosted Gateway
Cerbi Core deploys into a customer-controlled Azure subscription with private networking, managed identity, and immutable service images.
Controlled previewCustomer-hosted OpenTelemetry governance in Microsoft Azure
Point OTLP at Cerbi. Keep your SDKs, collectors, and destinations.
Cerbi Gateway adds a governed OpenTelemetry boundary without adding a Cerbi SDK to every application. For workloads already emitting OTLP, adoption is usually an endpoint or Collector-route change. Gateway verifies signed policy, governs telemetry, records evidence, and forwards to the current observability platform.
No Cerbi SDK required
Usually an OTLP endpoint or route change
Keep existing OpenTelemetry instrumentation
Keep Splunk, Datadog, Elastic, Azure Monitor, or another destination
Runs inside the customer Azure tenant
AI is not required
How Gateway fits
Change the OTLP route. Keep everything else.
Gateway is not another application logging framework. It is a tenant-hosted enforcement point placed in the telemetry path that already exists.
Existing workloads
Applications, agents, or collectors
Keep the OpenTelemetry SDK, auto-instrumentation agent, platform integration, or Collector already producing OTLP.
OTLP/HTTPOTLP/gRPCExisting instrumentation
No Cerbi SDK
Cerbi Gateway
Verify, govern, and forward
Validate telemetryVerify signed policyApply field decisionsRecord evidence
Existing destinations
The observability stack stays
Existing dashboards, alerts, retention, analytics, incident response, and purchasing relationships remain intact.
SplunkDatadogElasticAzure MonitorSentinelOther OTLP
CerbiShield → signed policy → Gateway
Governance profiles are validated, signed, versioned, published, and verified before runtime activation.
Gateway → bounded evidence → CerbiShield
CerbiShield records policy, target, decision, exception, and operational evidence without becoming the raw-log destination.
Accurate boundary: no Cerbi SDK is required. The workload must already emit OTLP through a standard OpenTelemetry SDK, agent, platform integration, or Collector. Workloads with no OTLP path still need standard OpenTelemetry instrumentation.
Three-step adoption
Start with configuration, not another application rewrite.
Change the OTLP route
Point an existing OpenTelemetry SDK, auto-instrumentation agent, or Collector route at Cerbi Gateway. The application does not add a Cerbi runtime package.
Apply policy and keep the destination
Gateway verifies a signed Runtime Policy Bundle, governs telemetry, records bounded evidence, and forwards the result to the existing observability platform.
What changes
Unsafe telemetry becomes governed telemetry.
The exact action is policy-controlled: allow, mask, remove, block, reject, or attach governance context. This illustrative example shows why the boundary matters.
Before Gateway
{
"service.name": "checkout-api",
"user.email": "jane@example.com",
"authorization": "Bearer eyJ...",
"request.body": "{ full customer payload }",
"severity": "ERROR"
}Sensitive data is copied into indexes, archives, alerts, and every configured destination.
Illustrative governed result
{
"service.name": "checkout-api",
"user.email": "[MASKED]",
"authorization": "[REMOVED]",
"request.body": "[BLOCKED]",
"severity": "ERROR"
}The destination receives the governed result while CerbiShield retains bounded policy and decision evidence.
Business value
Govern centrally without replacing the telemetry estate.
Stop sensitive telemetry before it spreads
Apply policy before PII, secrets, oversized payloads, or disallowed fields are copied into downstream indexes, alerts, archives, and dashboards.
Adopt centrally instead of application by application
Start with workloads already emitting OTLP and govern them through a shared endpoint rather than introducing a new Cerbi SDK into every codebase.
Preserve the observability investment
Existing exporters, analytics, dashboards, retention, incident response, and purchasing relationships remain downstream and customer-controlled.
Turn policy into retained evidence
Track policy version, deployment target, activation result, governance decisions, exceptions, and operational health through CerbiShield.
Protect the last valid policy
Signed policy is verified before activation. Failed reloads do not silently replace a known-good runtime policy.
Keep telemetry inside the customer boundary
Cerbi does not operate a hosted raw-log relay. Gateway processing and the downstream telemetry path remain in the customer environment.
Why not ordinary Collector processors?
The differentiator is the governance system around enforcement.
OpenTelemetry processors are useful building blocks. Cerbi adds signed policy lifecycle, controlled distribution, evidence, exceptions, rollback protection, and one control model across central and in-process enforcement.
CapabilityTypical processor setupCerbi Gateway
Policy distributionLocal processor configurationSigned, versioned Runtime Policy Bundles
Change controlRepository and deployment specificCentral publishing, target history, and controlled rollout
Failure behaviorDepends on custom configurationVerify before activation and retain the last valid policy
EvidenceRequires separate implementationGovernance decisions and operational evidence in CerbiShield
ExceptionsManual configuration driftManaged exception and audit workflow
Enforcement optionsCollector path onlyGateway, CerbiStream, or both
Choose the enforcement point
Gateway, CerbiStream, or both.
Gateway is the lower-friction path for existing OTLP estates. CerbiStream remains available when policy must run inside a selected application before the first network hop.
DecisionCerbiStreamGateway
Policy runsInside the applicationAt the OTLP boundary
Cerbi SDK requiredYesNo
Typical adoptionApplication package and configurationEndpoint or Collector route change
Best starting pointSelected high-risk applicationsExisting OpenTelemetry estates
Existing destinationKeptKept
Can operate togetherYesYes
Evaluation
Prove the path with one non-production workload.
The initial evaluation preserves the existing destination and produces evidence before any broader rollout decision.
Request a Gateway evaluation- 01Choose one non-production workload that already emits OTLP.
- 02Deploy Cerbi Core and Gateway inside the customer Azure tenant.
- 03Change the OTLP endpoint or existing Collector route.
- 04Activate a sample signed governance policy.
- 05Compare allowed, governed, and rejected telemetry behavior.
- 06Review policy activation and evidence in CerbiShield.
Questions
Common Gateway questions.
Does an application need a Cerbi SDK?
No. Cerbi Gateway does not require a Cerbi application package. A workload that already emits OTLP can usually be adopted by changing its OTLP endpoint or an existing Collector route.
Does the application need any OpenTelemetry instrumentation?
It must emit OTLP somehow. That can be an existing OpenTelemetry SDK, auto-instrumentation agent, platform integration, or Collector. A workload that emits no OTLP today still needs one of those standard OpenTelemetry paths.
Does Gateway replace the current observability platform?
No. Gateway sits before the current destination. Splunk, Datadog, Elastic, Azure Monitor, Sentinel, Grafana, or another OTLP-compatible destination remains in place.
Does Cerbi receive the raw telemetry?
Cerbi does not operate a hosted raw-log relay. Gateway processes telemetry inside the customer environment. CerbiShield receives bounded governance and operational evidence rather than acting as the raw telemetry destination.
Can Gateway and CerbiStream be used together?
Yes. CerbiStream can govern selected high-risk applications at emission, while Gateway provides a central OTLP boundary for broader platform adoption.
Is Gateway generally available?
Not yet. The page describes the controlled preview while final image publication, deployment lifecycle, and Marketplace validation are completed.
Keep OpenTelemetry. Add a governed boundary.
Gateway remains a controlled preview while final runtime, image publication, deployment lifecycle, and Marketplace validation are completed.
Customer-hosted No Cerbi SDK Existing OTLP path Existing destination
