On-Premises Deployment

In a self-hosted deployment your team runs the AI Runtime gateway in your own cloud account, with its database, its cache and its incidence data. ByteHide provides the images, the infrastructure as code and the guides; the console and prompt classification stay ByteHide-hosted.

Enterprise

Self-hosted deployments are available on the Enterprise plan. The infrastructure code, the Helm chart and the step-by-step guides are delivered once you choose your cloud and deployment model. Contact sales to scope yours.

What Runs in Your Environment

Component	What it does	State
Gateway	Inspects LLM and MCP traffic, applies your policies, forwards to providers and MCP servers in gateway mode or returns a verdict in in-app mode. It also serves the control API the console uses to manage your organization	Stateless. Scales by adding replicas
PostgreSQL	Organizations, routes, policies, integrations, consumers, MCP catalog, alerts, playbooks, the audit log and every incidence	Persistent. The most critical data in the deployment
Redis	The map from gateway keys to organizations, configuration cache, shared rate and token limits, the firewall blocklist and the response cache	Semi-ephemeral. Rebuilt from PostgreSQL
Scheduler	Calls the gateway every few minutes to fire grouped alerts, quiet hours, anomaly checks, and scheduled reports	Stateless. Your cloud's native scheduler

The gateway containers write nothing to disk: all durable state lives in PostgreSQL and Redis.

See Architecture for how they fit together.

What Stays ByteHide-Hosted

Service	Used for	If your gateway cannot reach it
Classification service	Classifying prompt injection and jailbreak attempts. The gateway sends it, over TLS, only the text it needs to classify	The gateway fails closed and answers `503`. See Network Requirements
Console	Managing routes, policies, MCP servers and reviewing incidences. It is not distributed for self-hosting	Your team cannot manage the gateway from the console
ByteHide platform	Member sign-in, delivery of alert notifications and SIEM forwarding	Inspection keeps working, and alerts are still evaluated and recorded, but notifications and SIEM events do not leave. Playbook steps that notify or forward to a SIEM do nothing
IP reputation	Country, network and reputation of the caller in incidences	Incidences lose origin details. Nothing else changes

PII and secrets detection run inside the gateway, in your environment.

Text sent for classification leaves your network

Prompt classification is ByteHide-hosted in every deployment option, so the text the gateway classifies is sent to ByteHide's classification service. Requests to your model providers and MCP servers do not pass through ByteHide.

Install Options

Option	Use it for	What ByteHide delivers
Managed Kubernetes (EKS, AKS, GKE)	Production. Recommended	A Helm chart with values per cloud, plus Terraform and Pulumi for the cluster and its dependencies
Virtual machines with Docker Compose	A proof of concept, a single team, or a gateway inside your own data center next to private MCP servers	Terraform and Pulumi for AWS, Azure and Google Cloud
Managed container services (ECS/Fargate, Container Apps, Cloud Run)	Teams that do not manage clusters or machines	A documented reference design, without code

Terraform and Pulumi are equivalent: use the one you already run. Native CloudFormation and ARM templates are not provided.

Kubernetes is recommended because the critical steps of a deployment are expressed natively: database migrations finish before the new version starts, and each replica gets a startup window before it takes traffic.

One virtual machine is not high availability

A single VM is a single point of failure, and an upgrade leaves a window without service. For production on VMs, run several instances across availability zones behind the load balancer, or use a managed scaling group (Auto Scaling Group, Virtual Machine Scale Set or Managed Instance Group) that also replaces an instance that stops responding. With more than one replica, Redis is required.

What the Infrastructure Code Provisions

Piece	AWS	Azure	Google Cloud
Private network	VPC, public and private subnets, route tables, NAT	VNet, subnets, NAT Gateway	VPC, subnets, Cloud NAT
PostgreSQL	RDS	Azure Database for PostgreSQL Flexible Server, with PgBouncer	Cloud SQL
Redis	ElastiCache	Azure Cache for Redis	Memorystore
Cluster or machines	EKS and node groups	AKS and node pools	GKE and node pools
Secrets	Secrets Manager	Key Vault	Secret Manager
Firewall and identity	Security groups, IAM roles	Network security rules, managed identities	Firewall rules, service accounts
Ingress	ALB or Ingress	Application Gateway or Ingress	Load balancer or Ingress
Migrations and scheduler	Blocking migration job and scheduler	Same	Same

The modules are parameterized: one profile variable sets the machine type, the container resources and the detection options together. Each example file is commented variable by variable.

The code also applies secure defaults: secrets are generated straight into the cloud's secret manager, never into plain variables or Terraform state; management and development paths are blocked at the load balancer as well as disabled in the gateway; and migrations run as a blocking step before traffic is served.

Deployment Steps

Before you start

Check Requirements and Network Requirements, and decide the decisions listed under Plan the Deployment below.

1. Get the Images

Pull the gateway image from ByteHide's registry with the read-only credentials ByteHide provides. You can mirror it to your own registry and deploy from there. Detection models are included in the image, so the deployment does not need to download them.

2. Provision the Infrastructure

Apply the Terraform or Pulumi code for your cloud and model: network, PostgreSQL, Redis, cluster or machines, secrets, firewall rules, load balancer and scheduler.

3. Run the Database Migrations

Run the migrations as a separate, blocking job, from the same image, before any replica starts. Only this job gets the direct database URL with schema-change privileges. If it fails, the deployment stops: no traffic is served against a half-migrated schema.

4. Start the Gateway

Roll out the replicas, only if the migration job succeeded. The first start takes one to three minutes while the gateway loads its detectors into memory, so give the startup probe a margin of 180 to 300 seconds.

5. Connect It to Your Organization

ByteHide registers your gateway's URLs on your organization, so the console manages routes and policies on your gateway instead of the SaaS one. The console's code examples then use your gateway's URL.

6. Integrate Your Applications

Point your applications and agents at your gateway's URL, exactly as with the SaaS gateway. See Gateway Mode, In-app Mode and MCP Protection.

Start in Observe

Every detector can run in Observe mode: it evaluates and records without blocking. Roll out in Observe, review what would have been blocked on real traffic in Incidences, and switch to enforcement once false positives are acceptable. See Policies.

Plan the Deployment

Decision	Why it matters
Cloud, region and deployment model	The region sets where your configuration and incidence data reside
PII detection profile	The setting that moves the gateway's memory the most. See Requirements
High availability	Number of replicas and zones. With more than one replica, Redis is required
Connectivity to ByteHide	Classification is always required. Closing the path to the ByteHide platform keeps inspection running but stops notifications, SIEM forwarding and console sign-in
Retention	Every inspected request is stored as an incidence. Decide how long you keep them before going live
Content storage	Each route can skip storing prompt and response text, keeping only the verdict and detections. See Privacy in Routes

Upgrades

ByteHide publishes each gateway version as a new image, with its SBOM, its signature and a CVE scan of the base image. Verifying the signature at admission is part of your cluster's configuration.

An upgrade repeats three steps:

Pull (or mirror) the new image.
Run the migration job with the new image, and stop if it fails.
Roll the replicas to the new image.

Your infrastructure only changes when the infrastructure code does. Migrations are additive first, so replicas still running the previous version keep working during the rollout.

Operations

Area	What to plan
Data retention	The gateway does not purge incidences on its own. Define a retention policy and automate the purge procedure from the operations guide
Backups	PostgreSQL holds your configuration and your full incidence history: use your managed service's automated backups and point-in-time recovery, and test a restore. Redis needs no backup, but test re-seeding gateway keys from the control plane, because until they are re-seeded the gateway answers `401`
Encryption key	Provider secrets are encrypted at rest with a key from your secret manager. Keep it backed up separately, and check on every restore test that it decrypts the restored secrets. It rotates through a key ring: add the new key in front, re-encrypt, then retire the old one. Never replace it outright
Redis incidents	A replica that starts while Redis is unreachable stays in local memory mode, and its rate limits and automatic bans stop being shared. Restart the replicas after any Redis incident, and alert on it
Health checks	The health endpoint only reports that the process answers. Add a synthetic end-to-end check through a route, and alert on startup errors in the logs
Tracing	The gateway exports traces over OTLP with W3C `traceparent` propagation, configured with the standard OpenTelemetry environment variables. Every response carries an `x-bytehide-request-id` for correlation
Environments	Run a separate deployment per environment
Disaster recovery	Recovery objectives and cross-region replication of PostgreSQL and Redis are agreed and tested during the deployment phase. The gateway itself redeploys anywhere from the infrastructure code

Responsibilities

ByteHide	Your team
Gateway images and registry credentials	The cloud account and its permissions
Terraform, Pulumi and the Helm chart	Region choice and network design
Deployment, operation and hardening guides	TLS certificates and domain names
Secure default configuration	Data retention policy
The classification service, the console and the ByteHide platform	Operating, scaling, backing up and upgrading the deployment