Skip to main content
HoneyHive separates the Control Plane from the Data Plane so your application data (traces, evaluations, datasets) never touches the control plane infrastructure. This federated architecture is the foundation of HoneyHive’s security model and determines where your data lives.

Your data stays isolated

Trace and evaluation data is stored in the Data Plane, which has no shared database or credentials with the Control Plane.

You choose where it lives

Deploy the Data Plane in any AWS region, in your own cloud account, or on-premise. See Hosting Models.

Nothing changes when you scale

Move from shared to dedicated infrastructure without changing your SDK integration or workflows.

How It Works

HoneyHive runs as two independent planes:
  • Control Plane β€” handles authentication (SSO, SAML 2.0, email/password, MFA), role-based access control, and organization/workspace/project configuration. Stores organizational metadata in PostgreSQL. Has no access to your trace data.
  • Data Plane β€” handles trace ingestion, event enrichment, evaluation jobs, and LLM proxy. Operates on its own databases and message queues. Verifies access using short-lived, cryptographically signed tokens issued by the Control Plane.

Control Plane Services

The Control Plane manages authentication, authorization, and platform configuration. It has no access to your trace or evaluation data.

Control Plane Data Stores

Data Plane Services

The Data Plane processes and stores all application data. It verifies access using JWT tokens issued by the Control Plane via a JWKS endpoint β€” the two planes share no database or credentials.

Data Plane Data Stores

Event Processing Pipeline

The ingestion pipeline is designed for high throughput, low latency, and zero data loss:
  1. Ingestion β€” the SDK sends traces to the Ingestion Service via OTLP-compatible HTTP or gRPC. The service validates API keys, normalizes incoming events, and publishes to encrypted NATS streams. Receipt is acknowledged immediately to minimize client latency.
  2. Writing and enrichment β€” the Writer Service pulls events from the CP NATS stream in batches. It enriches events in real time (session linking, metadata inheritance, computed fields) and writes them to ClickHouse. Failed batches are retried with exponential backoff; persistently failing events are sent to a dead letter queue on S3.
  3. Evaluation β€” the Evaluation Service consumes from the DP NATS stream and executes configured evaluators. Python metrics run in the sandboxed Python Metric Service. LLM-based evaluators route through the LLM Proxy. Scores are published to the CP NATS stream, where the Writer Service persists them to ClickHouse.

Message Queues

HoneyHive uses NATS with JetStream for durable, at-least-once message delivery: In production, the Control Plane and Data Plane run separate NATS clusters. The CP NATS cluster uses TLS for external communication. The DP NATS cluster runs internally with no external access.

ClickHouse Schema

ClickHouse stores data in four primary tables:

Hosting Models

The federated architecture enables three hosting options. In all models, the Data Plane’s databases are fully separate from the Control Plane.
Moving from Multi-Tenant SaaS to Dedicated Cloud or Self-Hosted increases physical isolation without changing how you use the platform β€” your SDK integration, dashboards, and workflows stay the same.
For self-hosted deployments, see Infrastructure Requirements for supported dependency versions and required operators.

Data Residency

You control where your AI application data is stored: For Dedicated Cloud and Self-Hosted customers, HoneyHive supports private connectivity via AWS PrivateLink and VPC Peering so trace data never traverses the public internet. For detailed data flow diagrams, data classification, and retention controls in self-hosted deployments, see Data Flow & Residency.

Reliability & Performance

High Availability

  • Multi-AZ deployment β€” services and databases distributed across multiple availability zones
  • Automatic failover β€” database and compute resources automatically failover on failure
  • NATS clustering β€” 3-replica NATS clusters with JetStream for durable message delivery
  • Health checks β€” continuous monitoring with automatic recovery
  • Zero-downtime deployments β€” rolling updates ensure no interruption during platform upgrades

Scalability

  • Horizontal auto-scaling β€” Kubernetes HPA scales pods based on CPU and memory utilization
  • Independent scaling β€” Control Plane and Data Plane scale independently based on their respective workloads
  • Queue-based buffering β€” NATS decouples ingestion from processing, absorbing traffic spikes with at-least-once delivery guarantees
  • Batch processing β€” the Writer Service buffers and batches writes to ClickHouse for optimal throughput

Security

For encryption, network security, infrastructure details, and compliance certifications, see Security.