Dedicated & Self-Hosted
Both private deployments run the same gateway as the SaaS service, with the same policies and console. The difference is where it runs, who operates it, and how your traffic reaches it.
Enterprise
Dedicated and self-hosted deployments are available on the Enterprise plan. Contact sales to scope yours.
Dedicated Gateway
ByteHide runs a gateway for your organization only, in a dedicated cloud account.
| Property | Description |
|---|---|
| Single tenant | Its own gateway, control plane, database and cache. Nothing is shared with the SaaS gateway or other customers, and your organization either starts fresh in it or is migrated from the SaaS gateway at cutover, with its configuration, history and provider secrets, re-encrypted with the dedicated gateway's own key |
| Private data plane | Your applications and agents reach the gateway from your network, over private connectivity such as a site-to-site VPN to your data center. The data plane is not published on the internet. If a hosted AI client must call your MCP routes, the MCP endpoint alone can be published to that client's source ranges |
| Private MCP servers | The gateway reaches MCP servers inside your network through the same private connection. Only the addresses agreed with ByteHide are allowed as private destinations |
| Same console | Your team keeps using the ByteHide console. Your organization is configured with its own gateway URLs, so the console manages routes and policies on your dedicated gateway |
| Controlled egress | Outbound traffic to model providers and to ByteHide's classification service leaves from fixed addresses you can allow-list on your side. Traffic to MCP servers in your network goes through the private connection instead |
| Availability | The gateway runs as several stateless replicas, with rolling updates that roll back automatically when a new version fails its health checks. The private connectivity can use an active/standby pair of peers on your side, with automatic failover to the standby |
| Encryption and secrets | TLS in transit, including to the database and cache. Secrets are kept in the cloud provider's secret manager, never in configuration files |
| Audit | Configuration changes are recorded in the Audit log, and the cloud account keeps its own audit trail |
| Operated by ByteHide | ByteHide deploys updates, monitors the service and handles incidents, in coordination with you for anything that touches the connectivity |
The Playground and code examples use the private URL
On a dedicated gateway, the console's code examples and the Playground use your private data-plane URL, so they only work from inside your network.
Self-Hosted
Your team runs the gateway in your own cloud account, with the deployment kit ByteHide provides:
- Container images of the gateway.
- Infrastructure as code for AWS, Azure and Google Cloud (Terraform and Pulumi).
- A Helm chart for managed Kubernetes (EKS, AKS, GKE), the recommended setup for production. Virtual machines with Docker Compose suit a proof of concept or a single team.
- Deployment, operation and hardening guides, and secure defaults.
The gateway runs as stateless containers that scale horizontally, backed by a PostgreSQL database and a Redis cache in your account.
Sizing, regions and the deployment procedure are agreed with ByteHide when you choose your cloud and deployment model.
Prompt Classification
In every deployment option, prompt classification is served by ByteHide's hosted classification service. The gateway sends it, over TLS, only the text it needs to classify. PII and secrets detection run inside the gateway itself.
Next Steps
Network Requirements
Connectivity to prepare for a private deployment
Deployment Options
Compare SaaS, dedicated and self-hosted