HoneyHive Dedicated Cloud: how do we deploy single-tenant in our AWS/Azure/GCP region with private networking and SAML SSO?

Quick Answer: Yes. HoneyHive Dedicated Cloud lets you deploy a single-tenant HoneyHive instance into your own AWS, Azure, or GCP region, connect it over private networking, and integrate with your existing SAML SSO and RBAC controls as part of our Enterprise offering.

Frequently Asked Questions

How does HoneyHive Dedicated Cloud single-tenant hosting work in AWS, Azure, and GCP?

Short Answer: HoneyHive Dedicated Cloud is a single-tenant deployment of HoneyHive provisioned in your chosen AWS, Azure, or GCP region, managed by HoneyHive but logically isolated from other tenants.

Expanded Explanation:
On the Enterprise plan, we deploy HoneyHive as a dedicated Kubernetes-based environment in your preferred cloud provider and region. This gives you tenant isolation, control over data residency, and the ability to integrate with your existing security stack—while HoneyHive manages the platform, upgrades, and reliability.

You get all the same modules—Traces, Monitors, Alerts, Experiments, Evaluators, Playground, and Annotations—but backed by infrastructure that’s scoped to your organization. For many teams, this is the middle ground between shared SaaS and fully self-hosted: HoneyHive operates the stack, you retain residency, isolation, and governance alignment.

Key Takeaways:

• Single-tenant HoneyHive runs in your chosen AWS, Azure, or GCP region.
• HoneyHive operates and maintains the stack while you retain isolation and residency control.

---

What is the process to deploy HoneyHive Dedicated Cloud in our cloud and region?

Short Answer: Deployment starts with an enterprise onboarding call, followed by cloud/region selection, networking and SSO design, and then HoneyHive provisions and validates your single-tenant environment.

Expanded Explanation:
We treat Dedicated Cloud as an implementation project, not just a toggle. The core steps are: align on your security and compliance requirements, pick the cloud and region, design private networking (VPC/VNet peering, PrivateLink/Private Service Connect, etc.), and configure SAML SSO and RBAC. HoneyHive then provisions the environment via Kubernetes in your chosen cloud, wires in monitoring, and runs validation before you connect production workloads.

You integrate your agents and apps the same way you would with multi-tenant SaaS—via our OpenTelemetry-native SDKs or OTLP ingestion—but the endpoints point to your dedicated environment. This lets you start sending traces and evaluations from production while staying inside your network and residency boundaries.

Steps:

1. Requirements + design: Align on cloud provider, region, compliance controls, and networking/SSO needs with the HoneyHive team.
2. Provisioning: HoneyHive deploys a Kubernetes-based single-tenant HoneyHive stack into your selected region and configures observability, logging, and backups.
3. Integration + validation: You connect via private networking, set up SAML SSO/RBAC, and run pilot traffic through Traces, Evaluators, and Alerts before broad rollout.

---

What’s the difference between Dedicated Cloud and full self-hosting?

Short Answer: Dedicated Cloud is HoneyHive-managed single-tenant in your cloud/region; self-hosting is customer-operated HoneyHive where you run and manage the entire stack yourself.

Expanded Explanation:
Both models give you isolation and control, but they differ in operational ownership. With Dedicated Cloud, HoneyHive provisions and manages the environment in your cloud account or a HoneyHive-managed account in your chosen region. We handle upgrades, patches, and platform reliability, while you focus on instrumenting agents, defining evaluations, and wiring alerts into your workflows.

With full self-hosting, your team runs HoneyHive on its own Kubernetes clusters in AWS, Azure, or GCP (including on-prem-friendly patterns). You own the infra, the runtime, and the operational playbooks; HoneyHive provides the software and guidance. Teams typically choose Dedicated Cloud when they want isolation and residency without building a new internal SRE surface area, and self-hosting when they have strict internal infra mandates or must keep everything inside their own accounts.

Comparison Snapshot:

• Dedicated Cloud: HoneyHive-managed single-tenant in your selected cloud/region; minimal infra burden for your team.
• Self-hosted: You run HoneyHive on your own Kubernetes clusters in AWS/Azure/GCP (and potentially on-prem) with full operational ownership.
• Best for:
  • Dedicated Cloud: Enterprises wanting isolation, residency, and private networking without operating the platform themselves.
  • Self-hosted: Organizations with hard requirements to run everything in their own accounts and SRE runway to manage the stack.

---

How do private networking and SAML SSO work with HoneyHive Dedicated Cloud?

Short Answer: HoneyHive Dedicated Cloud can be connected over private networking (e.g., VPC/VNet peering or private endpoints) and supports SAML-based SSO with fine-grained RBAC for project and workspace isolation.

Expanded Explanation:
For networking, we’ll work with your security and network teams to design a private path between your services and HoneyHive. In practice this often means VPC/VNet peering, PrivateLink/Private Service Connect, or equivalent private endpoint mechanisms in AWS, Azure, or GCP. The goal is to keep traffic between your agents and HoneyHive off the public internet, while still letting you ingest OTLP traces and use the web UI.

On identity, HoneyHive supports SAML/SSO so you can centralize auth in your existing IdP (e.g., Okta, Azure AD, etc.) and control access via enterprise RBAC. You can define custom permission groups and separate projects/workspaces to keep teams and environments isolated. For Dedicated Cloud, we configure SAML and RBAC as part of onboarding so access patterns are aligned with your internal security model from day one.

What You Need:

• Networking primitives in your cloud (e.g., VPC/VNet, private endpoints, and routing rules) plus a security contact to align on connectivity.
• An SAML-capable identity provider and group/role mapping for HoneyHive’s RBAC and workspace/project structure.

---

Why should we choose HoneyHive Dedicated Cloud for production AI observability and evaluation?

Short Answer: Dedicated Cloud gives you HoneyHive’s full observability and evaluation stack—with OpenTelemetry-native integration, online evals, and CI/CD checks—delivered in a single-tenant environment that matches your security, residency, and compliance requirements.

Expanded Explanation:
Production AI agents fail in subtle ways: silent failures, tool misuse or looping, unsafe outputs, PII leakage, and quality drift that only shows up on live traffic. HoneyHive is built to close that loop with three connected workflows: distributed traces that show every span across your agents and tools; automated and human evaluations that quantify quality alongside latency and cost; and a regression-prevention loop that turns production traces into datasets, experiments, and CI checks.

Dedicated Cloud lets you run that workflow with enterprise-grade isolation and governance. You stay aligned with SOC 2 Type II, GDPR, and HIPAA requirements, leverage SAML/SSO and fine-grained RBAC, and choose a deployment option that fits how your org already runs critical systems—multi-tenant SaaS, single-tenant Dedicated Cloud, hybrid, or fully self-hosted. The outcome is simple: faster root-cause analysis, safer agents in production, and more confident releases without compromising your security posture.

Why It Matters:

• You standardize AI observability and evaluation across teams while meeting security, residency, and compliance requirements.
• You reduce operational risk from AI agents—catching regressions, unsafe outputs, and drift—without building a custom internal observability stack.

---

Quick Recap

HoneyHive Dedicated Cloud gives you a single-tenant HoneyHive environment in your chosen AWS, Azure, or GCP region with private networking, SAML SSO, and fine-grained RBAC. It’s designed for teams that need isolation and residency but still want HoneyHive to operate the platform. You get the same production-first capabilities—OpenTelemetry-native Traces, online/offline Evaluators, Alerts and drift detection, Experiments, and CI/CD integration—backed by security controls aligned with SOC 2 Type II, GDPR, and HIPAA.

Next Step

Get Started