Data Flow & Residency

HoneyHive’s federated architecture separates the Control Plane (CP) from the Data Plane (DP). In a self-hosted deployment, both planes run inside your environment, so no customer data leaves your infrastructure boundary. Data Planes are built to operate independently from the Control Plane, so telemetry ingestion and evaluations continue running with no downtime even if the CP is temporarily unavailable. This page explains what data exists, how it moves between planes, and what controls you have over retention and deletion. For background on how the planes work together, see Platform Architecture.

​

Data Classification

HoneyHive processes three categories of data. Understanding the classification determines where each category is stored and how it crosses the CP/DP boundary.

​

Control Plane and Data Plane Boundary

The CP and DP are logically independent — they run on separate databases, separate message queues, and separate compute. Even in a self-hosted deployment where both are within your infrastructure, the boundary is enforced to ensure defense-in-depth and to support future migration to dedicated or hybrid hosting models.

​

What crosses the boundary

​

What stays within each plane

​

Data Flow

​

Ingestion path

1. Your application SDK sends traces to the DP Ingestion Service via HTTPS. The service acknowledges receipt immediately to minimize client latency.
2. The Ingestion Service immediately writes raw trace payloads (including LLM inputs/outputs) to DP S3 to ensure zero data loss, then publishes telemetry metadata to the CP NATS queue and evaluation events to the DP NATS queue.
3. The CP Writer Service consumes metadata from CP NATS, enriches it (session linking, metadata inheritance), and batch-writes to ClickHouse for dashboards, charts, and alerting.
4. Failed write batches are retried with exponential backoff; persistently failing events go to a dead letter queue on S3.

​

Evaluation path

1. The DP Evaluation Service consumes events from the DP NATS queue and executes configured evaluators (Python-based, LLM-based, or composite).
2. Evaluation scores (numeric results, pass/fail, labels) are published to the CP NATS queue as telemetry metadata.
3. The Writer Service persists scores to ClickHouse alongside the original trace metadata.

​

Authentication path

The Data Plane verifies API keys and user tokens using the CP’s JWKS endpoint. No shared database or credentials exist between the planes.

​

Data Stores

​

Data Plane stores

​

Control Plane stores

​

PII Controls

HoneyHive provides multiple layers to control how personally identifiable information (PII) is handled:

​

SDK-level redaction

The SDK supports schema-based PII filters that strip or mask sensitive fields before data leaves your application. Configure redaction rules to remove names, emails, phone numbers, or any custom fields from trace payloads at the source. For background on how tracing captures data and where to apply redaction, see Tracing Concepts.

​

Data Plane boundary

Raw trace payloads (which may contain PII) are stored exclusively in the Data Plane’s S3. Only telemetry metadata (durations, counts, scores) crosses the boundary to the Control Plane. This means even if PII reaches the Data Plane, it does not propagate to the analytics layer.

​

Encryption

All data at rest is encrypted with customer-managed KMS keys. All data in transit uses TLS 1.2+. See Security for full encryption details.

​

Retention Controls

Data retention is customer-configurable at multiple levels:

​

Deletion and Purge

​

Project-level archival

Deleting a project archives it — data is retained and can be recovered if needed. If the team is confident the original data should be permanently removed, they must purge the S3 store and ClickHouse index using escalated infrastructure privileges. This two-step design protects against accidental data loss.

​

Record-level deletion

HoneyHive is designed as an audit trail, so individual record deletion is not exposed through the standard API or UI. Deletions require infrastructure-level escalated privileges to ensure data integrity and auditability.

​

Infrastructure-level purge

For complete data removal (e.g., decommissioning a deployment):

1. S3: Delete all objects and the bucket itself, or apply an immediate-expiration lifecycle rule
2. RDS: Delete the database instance and all automated backups
3. ClickHouse: Drop the database or delete the EKS persistent volumes
4. EKS: Tear down the cluster via Terraform destroy

Since you own all infrastructure in a self-hosted deployment, you have full control over data destruction. No data residues remain on HoneyHive-managed systems.

​

Summary