Skip to content
DeepIntShield DeepIntShield DeepIntShield

Deployment options

DeepIntShield offers three deployment shapes. They share the same gateway and APIs; what changes is where your data lives, who operates the infrastructure, and the latency and availability envelope.

DeepIntShield Cloud

Fully hosted at app.deepintshield.com. Nothing to deploy - sign up, create a virtual key, and point your SDK at the gateway. Best for most teams.

Enterprise VPC

The data plane runs in your own cloud (GKE / AKS / EKS); DeepIntShield manages the control plane. No prompt, response, key, or audit data leaves your VPC. Best for strict data-residency and compliance requirements.

Self-Hosted (Enterprise)

Run everything - control plane and data plane - in your own infrastructure, including fully air-gapped. Delivered with our solutions team. Talk to sales to scope it.

Which one should I choose?

Section titled “Which one should I choose?”
CloudEnterprise VPCSelf-Hosted
Where your data livesDeepIntShield CloudYour cloud accountYour infrastructure
Who operates itDeepIntShieldDeepIntShield (control plane) + you (data plane)You
Get startedMinutes - sign upGuided onboarding with our teamTalk to sales
NetworkUse app.deepintshield.comOutbound-only to the control plane; no public ingressNone required (air-gap option)
Best forMost teams; fastest pathData residency, regulated industriesAir-gapped, on-prem, full control

DeepIntShield Cloud

Section titled “DeepIntShield Cloud”

Hosted and operated by DeepIntShield. There is nothing to install - see the Gateway quickstart:

  1. Sign up at app.deepintshield.com.
  2. Add your provider keys and create a virtual key.
  3. Point your SDK or app at https://app.deepintshield.com.

Enterprise VPC

Section titled “Enterprise VPC”

You host the DeepIntShield data plane (gateway + guardrails + ML detectors, with your own Postgres, Redis, and vector store) in your GKE / AKS / EKS cluster. DeepIntShield runs the control plane at app.deepintshield.com for policy authoring, dashboards, and billing.

What stays in your VPC: every prompt, completion, embedding, retrieved chunk, provider key, and audit record. Only signed configuration flows down and aggregate counts flow up, over a single outbound-only, pinned mutual-TLS connection - there is no inbound path into your environment, and the control plane is not on the ordinary request hot path. Local policy enforcement, configuration-cache misses, instrumentation, and upstream calls still add workload-dependent latency; benchmark the complete VPC path under expected concurrency and failure modes.

See Enterprise VPC deployment for the step-by-step install.

Self-Hosted (including air-gapped)

Section titled “Self-Hosted (including air-gapped)”

Run the full stack - control plane and data plane - entirely in your own infrastructure, including fully air-gapped environments. Self-hosting is an Enterprise offering delivered with our solutions team, who provide the deployment bundle, license, and a guided rollout for your platform (GKE, EKS, AKS, on-premise, or air-gapped).

Optional agent worker

Section titled “Optional agent worker”

SDK and Server 3.2.0 support server-managed LangGraph onboarding when your operator enables it on the gateway and supplies the isolated worker runtime. The operator can enable it for every workspace at once; limiting it to selected workspaces is optional. Ordinary gateway hosting does not enable that worker. The default runner requires an operator-managed Docker host, immutable images, shared staging storage, enforced egress policy, and HTTPS gateway access. As an optional deployment alternative, the gateway can send each run over HTTPS to a separately deployed worker service that runs the same pinned worker image; the operator must restrict that service to the gateway and give every run a fresh, isolated instance. Native Cloud Run or Kubernetes hosting of the gateway alone does not provide either runtime.

Confirm worker availability with your service operator and that the worker image contains every package your program imports. The worker runs its own SDK, Python and package releases; your client’s versions are recorded as evidence and never need to match. Local Agentic execution remains the default.

Next steps

Section titled “Next steps”