Skip to content
Home

Product

Enterprise-grade BYOC.

Bring your own cloud. Cardinal runs against your object storage, in your account, with your networking, IAM, and key management. Nothing leaves your perimeter, and you are not on your own operating it.

What BYOC means here

  • Data plane deployed inside your cloud account (AWS, GCP, Azure) or on-prem
  • On-prem needs Kubernetes, Postgres, S3-compatible storage, and elastic capacity
  • Indexes telemetry in place, with no vendor-hosted copies
  • SSO, SCIM, RBAC, and audit logs on the control plane
  • Bring your own KMS keys; no shared encryption

Operated, not just shipped

Your cloud, our operational burden.

BYOC usually means the vendor's problems become yours. These three are where that stops being true.

01 · Deployment & upgrades

How we manage the infra.

Cardinal runs in your cloud account, but running it is not left to you. The deployment is standard infrastructure-as-code against your cluster, and we operate it with you rather than handing over a Helm chart and wishing you luck.

  • One Kubernetes deployment: Cardinal UI, mcp-gateway, and Lakerunner
  • Helm and Kustomize, with IaC per cloud (AWS, GCP, Azure)
  • Stateless workers autoscale with volume; scale to near-zero when quiet
  • Upgrade policy with controls
  • We monitor the Cardinal components and do not have access to your data

02 · Health & telemetry

We watch the platform, not your data.

Two different things get called system health: whether your cluster thinks the pods are alive, and whether the pipeline is keeping up. Cardinal exposes both, and you decide who receives them.

  • /healthz, /readyz, and /livez on every component, for your cluster's own probes
  • Lakerunner emits OpenTelemetry metrics, logs, and traces about the components themselves, not about the telemetry they store
  • Ingest lag, compaction backlog, and query latency as operational signals
  • On by default it comes to us; redirect it to your own OTLP backend, send it to both, or configure no endpoint and nothing is exported
  • Point it at your own Cardinal install and your platform team sees exactly what we see

03 · Support channels

Slack, email, and a pager.

Three ways to reach a human, chosen by how much the answer can wait. Every one of them ends at the people who build the product rather than a tier-one queue.

  • Shared Slack channel with the engineers who build the product
  • Email for tracked, non-urgent requests
  • Paging path for production-down severity

Health, in practice

How Cardinal monitors your deployment.

This is what Cardinal SRE looks at for every customer-owned deployment. Point the same self-telemetry at your Cardinal install and your platform team gets the same view.

System health

Per-service CPU, memory, and replica counts.

One page per deployment: per-service memory in use vs. cache vs. limit, records ingested, per-worker headroom. Where every component sits against its resource limits.

Click to enlarge · esc to close

Cardinal fleet dashboard: KPIs, per-service CPU and memory, and memory-limit breakdown for a Cardinal deployment.

Autoscaling

HPA current, desired, and max, per signal.

Every processing lane has its own horizontal pod autoscaler. Current, desired, and max replica counts per signal, tracked across the day.

Click to enlarge · esc to close

HPA replica counts and per-signal record processing rates for logs, metrics, and traces.

Pipeline depth

Per-lane queue depth on ingest, compact, and rollup.

Depth over time for every stage of the pipeline. The signal that moves first, before anything shows up as user-facing latency.

Click to enlarge · esc to close

Per-lane queue depth for ingest, compaction, and rollup across log, metric, and trace pipelines.

Ingestion

Throughput and signal mix.

Records and bytes in and out, and the mix across logs, metrics, and traces. A change in the ratio from a new source or a trace pattern shows up here before it changes storage cost or query time.

Click to enlarge · esc to close

Ingestion dashboard showing records in and out, bytes in and out, and records by signal over the last hour.

Compaction & S3

Compaction pace and bucket I/O.

Compaction throughput against S3 upload and download rate. What Cardinal uses to tune the rollup ladder to your query pattern.

Click to enlarge · esc to close

Compaction rate in and out, and S3 upload and download bytes per second for a Cardinal deployment.

Deployment mode

Fully air-gapped.

Some environments have no path to the internet at all, by policy or by regulation. Cardinal runs there. Licensing validates offline against a signed envelope with no external calls, and telemetry exports nothing when no endpoint is configured, so nothing has to reach us for the platform to work.

Monitoring still works

  • /healthz, /readyz, and /livez for your cluster's own probes and alerting
  • Component self-telemetry to an OTLP endpoint inside the enclave
  • Point that at your own Cardinal install and monitor Cardinal with Cardinal
  • Ingest lag, compaction backlog, and query latency, unchanged

What you take on

  • Mirroring container images into your internal registry
  • Scheduling upgrades rather than accepting them
  • Watching platform health, since nothing is reported outward for us to notice
  • Exporting the evidence when you want us to look at something

You run more of it, but you do not run it alone. The Slack channel, the engineers, and the upgrade guidance are the same. The difference is that you bring the evidence to the conversation, because we cannot reach in and pull it ourselves.

See it in your own cloud.

The install flow stands Cardinal up in your account against your own bucket. No vendor-hosted copy of your telemetry.

Get started freeHow it fits togetherWhy nothing leaves your account →