AI Gateway Hybrid Infrastructure

The data plane processes every LLM request. The management plane is where you author configuration and read analytics. The Strata Cloud Manager API Gateway sits at the boundary and is the sole authentication authority for anything entering the management plane.

Session cookies are not used on management plane routes. Identity is established through three headers the SCM API Gateway injects into every request it forwards.

The load balancer in front of the Backend terminates mutual TLS (mTLS, where both sides present certificates) and forwards the verified client certificate subject. The Backend then re-verifies the certificate Common Name (CN), so gateway-injected identity headers are trusted only when the caller is genuinely the SCM API Gateway. None of these are values you configure; they are issued and verified inside the management plane.

Only the synchronous path affects response latency. Everything else runs after the client already has its answer.

Synchronous:

1. Entry — the application sends an LLM request to the gateway in your environment.
2. Auth and config hydration — the gateway checks Redis for the API key, organisation context, and routing configuration. A cache miss calls the Backend over the link, which reads MySQL and returns the hydrated object for the gateway to cache.
3. LLM proxying — the gateway forwards the request, with any configured transformations, to the target provider. The response streams back through the gateway.
4. Response return — the client's request ends here.

Asynchronous, non-blocking:

1. Metrics to ClickHouse — token counts, cost, latency, model, provider, cache status, and trace identifiers, plus a pointer to the full log body. These are written in batches.
2. Raw log to blob store — the complete request and response payload as a structured document. The file path matches the pointer in the ClickHouse record, which is how the Backend cross-references the two when serving log details.
3. Usage sync — updated usage counters, API key exhaustion events, and quota state.

Because config is cached locally, the gateway keeps serving traffic when the management plane is unreachable. It stops receiving configuration updates but continues to serve requests. That includes API key revocations, guardrail changes, and quota updates: a key revoked in SCM continues to be accepted by a disconnected gateway until the cached auth object expires. The cache TTL, and whether the gateway fails closed after it, are described in the cache behaviour documentation; confirm them with your account team and treat management plane reachability as a security control, not only an availability one.

This is the section to bring to a data protection review.

• Prompt content and LLM responses — in the current AIRS release these reach the Strata Cloud Manager backend and are stored there. Treat every prompt that passes through the gateway as data that has left your environment. On the Portkey product, LOG_STORE pointed at your own bucket keeps bodies in your account and a single body crosses the boundary each time an operator opens that entry; that is not the AIRS GA behavior.
• Crossing the boundary by default — metrics (tokens, cost, latency, model, provider, trace identifiers), usage counters, configuration sync, and, in the current AIRS release, full prompt and completion bodies.
• Log storage location — not customer-selectable in the current AIRS release, per the note above. Region, retention, and custody for the backend store are unpublished.
• In transit — TLS 1.3 between planes.
• At rest — all management plane data encrypted, with envelope encryption for sensitive fields.
• Bring Your Own Key (BYOK) — optional, with AWS Key Management Service (KMS), for management plane data at rest.
• Access control — network-level controls restrict management plane access to authorised IPs, administrative functions use scope-based access control, all administrative actions are audit logged, and access tokens are short lived with automatic rotation.

Strata Cloud Manager runs in the Americas only today, with other regions planned, so that is where backend-stored bodies land. See Open Questions before designing for EU residency.

The cache holds hydrated API key and routing objects, so treat it as a secret store. Require AUTH and in-transit encryption on the managed options, restrict the cache security group or firewall rule to the gateway node or pod CIDR on TCP 6379, and do not expose the built-in Redis through any Service of type LoadBalancer.

Sizing the log store is straightforward: each log document is roughly 10 kB uncompressed. Multiply by your request volume and retention window.

Set LOG_STORE_FILE_PATH_FORMAT to control how log files are laid out in the bucket.

Choose v2 if you intend to apply lifecycle rules or query by time period, which most retention policies need. Two constraints apply: changing the value affects only newly written logs, since existing objects are not migrated, and v2 is not supported for air-gapped deployments where LOG_STORE is set to control_plane.

ECS and Container Apps need no Kubernetes cluster; see ECS and Container Apps. Any other conformant cluster, including on-premises, is supported without a vendor page; see On-premises and private cloud clusters.

What the cluster has to provide, independent of platform:

The Palo Alto Networks administration documentation names any public cloud, private cloud, or on-premises Kubernetes cluster as a valid host, so vSphere with Tanzu, TKG, OpenShift, RKE2, Rancher, k3s, and self-built clusters on bare metal are all valid targets; work from the table above and the cloud pages, and confirm storage driver and ingress specifics with your account team before committing a customer to a date.

• Node count — at least 2 worker nodes on all three Kubernetes platforms.
• Availability — one node per Availability Zone is the documented best practice, and for ECS and Container Apps the equivalent is tasks or replicas spread across zones with autoscaling enabled.

No throughput figures are published, and neither the Data Service nor a self-hosted semantic cache has separate sizing; see Open Questions.

On the SCM registration path the gateway needs outbound HTTPS on 443 only: to api.portkey.ai for configuration and analytics and to registry.portkey.ai for the image. You do not need an inbound rule, a public load balancer, or a private link back to Palo Alto Networks, and no private option is documented for this path. On the platform-page path each cloud offers two options.

Service identifiers and procedures for Azure Private Link and GCP Private Service Connect are not published in the material this guide is based on; request them from your account team.

PrivateLink on AWS (platform-page path).

1. Send your AWS account ARN to the Palo Alto Networks team and wait for confirmation that it is whitelisted. Do this before you create the endpoint. An endpoint created earlier will show a rejected or failed state; delete it and create it again after the team confirms whitelisting.
2. In the AWS console open VPC, then Endpoints, then Create endpoint. Create an interface endpoint to service com.amazonaws.vpce.us-east-1.vpce-svc-0c2c1c323d9f56d95 in the gateway VPC. If the gateway runs outside us-east-1, create it as a cross-region endpoint targeting us-east-1.
3. When the endpoint shows Available, select it and use its Actions menu to enable Private DNS names. Verify from a pod that aws-cp.portkey.ai resolves to the endpoint's private addresses before you change values.yaml.
4. Add the four PrivateLink base paths below under the environment.data key in values.yaml. This is the same environment: map the AWS checklist later adds LOG_STORE settings to; keep one environment: block.

environment:
  create: true
  secret: true
  data:
      ALBUS_BASEPATH: "https://aws-cp.portkey.ai/albus"
      CONTROL_PLANE_BASEPATH: "https://aws-cp.portkey.ai/api/v1"
      SOURCE_SYNC_API_BASEPATH: "https://aws-cp.portkey.ai/api/v1/sync"
      CONFIG_READER_PATH: "https://aws-cp.portkey.ai/api/model-configs"

Kubernetes allows full egress by default. If your cluster applies restrictive NetworkPolicies, the gateway needs an egress allowance covering both the management plane and your LLM providers. Save the following as allow-egress.yaml and apply it with kubectl apply -f allow-egress.yaml after the Helm install has created the portkeyai namespace (or create the namespace first with kubectl create namespace portkeyai). kubectl apply is safe to re-run; it updates the existing policy in place.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress
  namespace: portkeyai
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0

This policy applies to every pod in the namespace and allows all egress. Before production, restrict podSelector to the gateway pods (use the chart's pod labels) and replace 0.0.0.0/0 with the VPC endpoint ENI addresses if you use PrivateLink, or the management plane egress ranges from your account team if you use the internet path, plus your LLM provider ranges and cluster DNS on UDP and TCP 53. Kubernetes NetworkPolicy cannot match hostnames, so the internet path needs an FQDN-capable CNI or an egress proxy to lock down further.

The platform deployment pages describe a second direction, running from the management plane inbound to your gateway over AWS PrivateLink, Azure Private Link, or GCP Private Service Connect, with IP whitelisting as the alternative. Do not build it.

Palo Alto Networks confirmed on 2026-09-27 that private link is not supported with Strata Cloud Manager today, and that the only network connectivity between a gateway and the cloud is outbound from the gateway. Those procedures describe the Portkey product, which shares the charts and the tooling but not this part of the architecture.

In practice that means three things you do not do:

• Do not create a VPC endpoint service, a Private Link Service, or a published Private Service Connect service for the gateway.
• Do not authorise arn:aws:iam::299329113195:root, or any Palo Alto Networks principal, into your account.
• Do not add 54.81.226.149, 34.200.113.35, or 44.221.117.129 to a load balancer security group. Your load balancer admits your own applications and nothing else.

A gateway registers and stays visible in Strata Cloud Manager on outbound connectivity alone. If it does not appear, the cause is in the outbound section above.

• EKS cluster — at least 2 worker nodes, ideally one per Availability Zone.
• Tooling — AWS CLI, kubectl, Helm v3 or above, and eksctl.
• S3 bucket — for LLM access logs, with encryption at rest and a lifecycle policy matching your retention requirement.
• Bucket access — either IAM Roles for Service Accounts (IRSA) or EKS Pod Identity. Both avoid static credentials. Create an IAM role trusted by the cluster's OIDC provider (IRSA) or by pods.eks.amazonaws.com (Pod Identity), with s3:PutObject, s3:GetObject, and s3:ListBucket on arn:aws:s3:::<AWS_BUCKET_NAME> and arn:aws:s3:::<AWS_BUCKET_NAME>/* (confirm the exact action list against the EKS platform page). With IRSA, eksctl create iamserviceaccount --name <SERVICE_ACCOUNT_NAME> --namespace portkeyai --cluster <CLUSTER> --attach-policy-arn <POLICY_ARN> --approve creates both the role and the annotated service account. With Pod Identity, aws eks create-pod-identity-association --cluster-name <CLUSTER> --namespace portkeyai --service-account <SERVICE_ACCOUNT_NAME> --role-arn <ROLE_ARN> makes the association.
• Cache store — ElastiCache for Redis OSS or Valkey in the same VPC, or the built-in Redis.
• External access — an Application Load Balancer with a Kubernetes Ingress, or a Network Load Balancer. With no inbound path to back, the choice is yours to make on its merits.
• Connectivity — per Connectivity.
• Credentials from Palo Alto Networks — per Complete these first. Create the pull credential as a kubernetes.io/dockerconfigjson Secret in portkeyai and reference it from imagePullSecrets rather than pasting it into values.yaml; put the Client Auth Key in a Secret referenced by the chart or delivered by your secrets operator. Anything that does go through values.yaml is stored in the Helm release Secret in the namespace, so restrict get secrets on portkeyai accordingly.

The snippet below is the published platform-page procedure for the Portkey chart. The key AIRS uses for a local log store is not confirmed, so on the SCM wizard path (airs-gw) these keys may have no effect; see Where prompt logs are stored for the trade a customer-held bucket involves before you plan around one. Apply it on the platform-page path, to the values.yaml you wrote from the EKS page. Merge, do not replace: keep environment.create, environment.secret, and every existing environment.data entry (including the PrivateLink base paths from Outbound if you set them), and add only the three LOG_STORE keys under data.

serviceAccount:
  create: true
  automount: true
  name: <SERVICE_ACCOUNT_NAME>
  annotations:
    eks.amazonaws.com/role-arn: <ROLE_ARN>

# ADD these keys under the environment.data already in your file
# (environment.create, environment.secret, and the existing data entries stay as they are)
environment:
  data:
    LOG_STORE: s3_assume
    LOG_STORE_REGION: "<AWS_BUCKET_REGION>"
    LOG_STORE_GENERATIONS_BUCKET: "<AWS_BUCKET_NAME>"

Scope the role to the one bucket, plus kms:GenerateDataKey and kms:Decrypt on the bucket key if you use SSE-KMS, and restrict the trust policy condition to system:serviceaccount:portkeyai:<SERVICE_ACCOUNT_NAME>. If the service account already exists in the portkeyai namespace (for example because you created it together with the IAM role using eksctl), set create: false so Helm reuses it instead of failing with an already-exists error. Check with kubectl get sa -n portkeyai.

For EKS Pod Identity the configuration is the same minus the annotation, since the association is made outside the chart. The service account name must match the one you referenced when creating the IAM role.

Verify before moving on: aws s3api head-bucket --bucket <AWS_BUCKET_NAME> returns 200, kubectl get sa <SERVICE_ACCOUNT_NAME> -n portkeyai -o yaml shows the role-arn annotation, and aws elasticache describe-cache-clusters lists your cache in the gateway VPC. Replace portkeyai with your release namespace if you used the SCM wizard's values.yaml. The post-install checks are under After install: confirm the link.

• AKS cluster — at least 2 worker nodes, ideally one per Availability Zone.
• Workload Identity — recommended. Requires the OpenID Connect (OIDC) issuer and Workload Identity both enabled on the cluster (az aks update with --enable-oidc-issuer --enable-workload-identity). Without it the gateway authenticates to Blob Storage with a storage account key held in values.yaml, which then lives in the Helm release Secret; if you take that route, use a key you can rotate and scope the account's network rules to the AKS subnet.
• Tooling — Azure CLI, kubectl, and Helm v3 or above.
• Storage account and container — for logs, with encryption at rest and a lifecycle rule for retention.
• Cache store — Azure Cache for Redis in the same VNet, or the built-in Redis.
• External access — an internal load balancer in front of the gateway Service or Ingress. No Private Link Service and no dedicated subnet for one is needed.
• Connectivity — Azure Private Link or internet, outbound only. There is no inbound path to build.
• Credentials from Palo Alto Networks — as for AWS.

With Workload Identity, add the following to the values.yaml you will install from, merging into the existing serviceAccount and environment blocks as on AWS:

serviceAccount:
  create: true
  automount: true
  name: <SERVICE_ACCOUNT_NAME>
  annotations:
    azure.workload.identity/client-id: <CLIENT_ID>

# ADD these keys under the environment.data already in your file
# (environment.create, environment.secret, and the existing data entries stay as they are)
environment:
  data:
    LOG_STORE: azure
    AZURE_STORAGE_ACCOUNT: <STORAGE_ACCOUNT_NAME>   # storage account holding the LLM logs
    AZURE_STORAGE_CONTAINER: <STORAGE_CONTAINER>    # blob container inside that account
    AZURE_AUTH_MODE: workload                        # 'workload' for workload identity, 'managed' for a managed identity

Set AZURE_AUTH_MODE to match the identity you configured above: use workload with Azure AD workload identity federation, and managed when the cluster reaches the storage account through a managed identity. Neither mode takes a storage account key, so there is no credential to rotate here.

Verify before moving on: az aks get-credentials followed by kubectl get nodes shows at least 2 nodes Ready; az storage container show --name <container> --account-name <account> returns the log container; the cache endpoint resolves and answers on 6380 from inside the VNet (or you have chosen the built-in Redis); and the cache endpoint is reachable from the node subnet. Any item that fails is safe to re-create; none of these commands changes state.

• GKE cluster — at least 2 worker nodes, ideally one per zone.
• Proxy-only subnet — the cluster VPC needs an ACTIVE subnet with purpose REGIONAL_MANAGED_PROXY in the cluster region, or the regional load balancer never provisions and Helm reports nothing. Create it first: gcloud compute networks subnets create <NAME> --network=<VPC> --region=<REGION> --range=<CIDR> --purpose=REGIONAL_MANAGED_PROXY --role=ACTIVE. Confirm with gcloud compute networks subnets list, filtering on purpose REGIONAL_MANAGED_PROXY, that one subnet in your region shows role ACTIVE.
• Workload Identity — must be enabled on the cluster and on the node pool before the bucket binding below will work.
• Tooling — gcloud CLI, kubectl, and Helm v3 or above.
• Cloud Storage bucket — for logs. Bind the gateway's Kubernetes service account to a Google service account through roles/iam.workloadIdentityUser, then grant that Google service account roles/storage.objectAdmin on the log bucket. Apply it at the bucket level rather than the project level. The published alternative is a custom role carrying only storage.objects.create and storage.objects.get, which is the tighter choice and the one to prefer, since objectAdmin also permits deletion.
• Cache store — Memorystore for Redis or Valkey in the same VPC, or the built-in Redis.
• External access — an internal load balancer in front of the gateway Service or Ingress. You do not publish it as a service attachment.
• Connectivity — Private Service Connect or internet, outbound only. There is no inbound path to build.
• Credentials from Palo Alto Networks — as for AWS.

• Sizing — ECS tasks with at least 1 vCPU (1024 CPU units) and 2 GiB per task.
• Availability — run tasks across multiple Availability Zones with autoscaling enabled.
• AWS permissions — to create ECS, EC2, VPC, ELB, IAM, S3, Secrets Manager, and CloudWatch resources. Run Terraform from a role scoped to those services, not from an administrator identity.
• Tooling — AWS CLI with credentials configured, and Terraform v1.13 or later.
• State and re-runs — configure a remote backend before the first apply so a failed run can be resumed; terraform apply is safe to re-run against the same state, and terraform destroy removes everything the configuration created. If local state was lost after a partial apply, import or delete the orphaned resources before re-applying. State holds resource identifiers and configuration, so keep it in an encrypted, access-controlled backend.
• Secrets — you create the Docker credentials and the Client Auth Key in AWS Secrets Manager yourself, before Terraform runs. The module is given the secret ARNs, not the values, and the task definition resolves each ARN at task start, so raw secret values do not enter Terraform state.
• Log store — Amazon S3 or any S3-compatible store, optional.
• Cache store — built-in Redis, or ElastiCache for Redis OSS or Valkey in the same VPC.
• Compute model — with create_cluster = true the module registers one capacity provider backed by an EC2 Auto Scaling group, so tasks run on container instances you own. Fargate is not a documented option; see ECS Fargate in the ECS and Container Apps guide for what the module actually supports.
• Connectivity — outbound to the management plane endpoints in Connectivity. There is no inbound path to build, so the load balancer type is yours to choose on its merits.

• Sizing — Container Apps with at least 1 vCPU and 2 GiB per replica.
• Availability — autoscaling across multiple Availability Zones.
• Azure permissions — to create Container Apps, Key Vault, Storage, VNet, and Application Gateway resources.
• Tooling — Azure CLI with credentials configured, and Terraform v1.5 or later.
• Secrets — Docker credentials, the Client Auth Key, and your Organisation ID are stored in Key Vault rather than passed as chart values.
• Log store — Azure Blob Storage or any S3-compatible store, optional.
• Cache store — built-in Redis or Azure Managed Redis.
• Connectivity — outbound to the management plane endpoints in Connectivity. There is no inbound path to build.
• Network — a VNet is optional, which is unique among the supported platforms. It becomes mandatory for zone redundancy, Application Gateway, and outbound Private Link.

The Key Vault entries the Terraform configuration expects are docker-username, docker-password, portkey-client-auth, and organisations-to-sync. Create the vault with RBAC authorisation enabled and grant yourself Key Vault Administrator to write the four entries. The module is given the secret names and the vault to resolve them against, not the values, so raw secret values do not enter Terraform state. Keep state in an encrypted backend regardless, because it still carries resource identifiers and configuration.

If a previous attempt created a vault with the same name and you deleted it, recover it (az keyvault recover --name <vault>) or purge it (az keyvault purge --name <vault>) before creating it again; soft-delete keeps the name reserved. To tear the deployment down, run terraform destroy, then recover or purge the vault if you intend to reuse the name.

Workspaces are sub-organisations that separate data, teams, scope, and visibility inside one organisation. They are the unit of multi-tenancy within a tenant.

• Team management — members are added with a role of manager or member.
• Dedicated API keys — each workspace has its own, either Service Account type for automation or User type for individuals. Both are scoped to the workspace and can only act within it.
• Completion API scoping — completion APIs are always scoped by workspace and reachable only with a workspace API key.
• Admin control — only org admins create workspaces; managers can then add API keys and members.
• Targeting from the org level — admin keys can specify a workspace_id to act on a particular workspace.

Access is enforced through the Scope Access header described in Identity and authentication, evaluated per request. Membership tables are never consulted at request time.

Deleting a workspace requires removing every resource inside it first, including prompts, prompt partials, providers, configs, and guardrails. The default Shared Team Workspace cannot be deleted, and deletion elsewhere is permanent.

If you finished Phase 2 of the deployment guide, your gateway is already registered and this section is background; do not click Add New Gateway again, since that creates a second gateway. Registration connects the gateway to the management plane and sets which workspaces may route through it. It is done once, in the SCM wizard under AI Security → AI Gateway → Admin Settings → Gateway Registration → Add New Gateway, and is covered click by click in Phase 2 of the deployment guide. The wizard's Workspace Provisioning stage offers Allow All Workspaces or Allow Specific Workspaces; Allow Specific Workspaces is the right choice when you need separate gateways per team, business unit, or compliance boundary.

Two points matter for infrastructure planning. First, the generated values.yaml targets the airs-gw chart, points at registry.portkey.ai, and is not a drop-in for the platform-page values.yaml this guide describes. Second, after the wizard closes the gateway appears in the list with a copyable Slug Name (for example dp-ai-gateway-5aa51a), its Type, a Connection Status, whether it is the Default, and Last Sync. Connection Status stays Unknown with Last Sync showing -- until running pods check in; after that they check in roughly every 30 seconds. Once pods are Running, the row should update within a couple of minutes. If it still reads Unknown after that, the pods are not reaching api.portkey.ai: check kubectl logs -n <namespace> <gateway-pod> for authentication or connection errors and confirm egress on 443. The guide cannot confirm whether the file has a validity window; if the pods report an authentication failure, register a new gateway and reinstall from the new file.

Total Gateways counts hybrid gateways only. The counter reads zero on a tenant already serving traffic through the SaaS gateway, because the SaaS gateway is a separate row above the list rather than an entry in it, so an empty list does not mean AI Gateway is unlicensed or inactive. The SaaS gateway stays enabled and any client still using the SaaS Gateway URL continues to send prompts to the Palo Alto Networks hosted plane. Once your clients are repointed at the hybrid endpoint and verified, switch the SaaS row's toggle off so no traffic can leave your network by the old path.

Run this after completing the deployment guide (path 1) or the platform page install (path 2). Do not rely on pod status. A gateway that starts cleanly and passes health checks can still be failing to reach the management plane.

1. Send a test request to the gateway with curl.
2. Open Strata Cloud Manager, select AI Security, then AI Gateway, then Observability in the left navigation, and switch to the Logs tab.
3. Confirm the request appears and that you can open it and see full details.

Replace GATEWAY_BASE_URL with the scheme, hostname, and port of the load balancer in front of the gateway (for example https://gateway.internal.example.com); it must be https:// unless you are port-forwarding to localhost. OPENAI_API_KEY is a key from your OpenAI account; any provider you have configured works if you change x-portkey-provider to match. PORTKEY_API_KEY is a workspace API key from SCM, created under AI Security → AI Gateway → Security Keys (deployment guide Phase 3, Step 3.8). Export the keys first so they do not land in shell history.

read -s OPENAI_API_KEY
read -s PORTKEY_API_KEY
export OPENAI_API_KEY PORTKEY_API_KEY

curl '<GATEWAY_BASE_URL>/v1/chat/completions' \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "x-portkey-provider: openai" \
  -H "x-portkey-api-key: $PORTKEY_API_KEY" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [{"role": "user", "content": "What is a fractal?"}]
  }'

Wait about a minute; pods report to the management plane roughly every 30 seconds. Replace portkeyai in the commands below with your release namespace if you used the SCM wizard's values.yaml.

• The curl fails — check kubectl get pods -n portkeyai and kubectl logs -n portkeyai <gateway-pod> for image pull or startup errors and return to the checklist for your platform. If a pod is stuck in ImagePullBackOff, run kubectl describe pod -n portkeyai <pod> and check the Docker credentials against the ones issued for your Organisation ID. If a pod is in CrashLoopBackOff, check kubectl logs -n portkeyai <pod> for a missing environment value and compare against the Outbound and log store snippets. Re-run helm upgrade --install after correcting values.yaml.
• The request succeeds but never appears in Logs — the outbound path is working and the log or sync path is not. Check Connection Status and Last Sync under Gateway Registration, look for sync errors in the gateway pod log, then re-check the base paths in Outbound.
• The entry exists but the log detail view is empty — check the LOG_STORE settings in values.yaml rather than connectivity.

There are two independent monitoring paths, and you want both.

• Prometheus metrics — the gateway serves GET /metrics on its own container port (8787), enabled by default. Set ENABLE_PROMETHEUS=false to switch it off, which unregisters the middleware and makes the path return 404. Scrape it from inside the cluster only, with a ServiceMonitor or scrape job against the gateway Service; do not include that port in the load balancer listener or in any security group rule that also serves the management plane or the internet.
• The metrics endpoint is unauthenticated by default — the upstream documentation describes access as typically open and advises securing it yourself. Because it shares the gateway's container port rather than sitting on a separate admin port, any ingress that exposes the gateway also exposes /metrics unless you block the path. If your ingress is internet-facing, add a path rule denying /metrics and scrape the Service directly from inside the cluster.
• Analytics export — ClickHouse analytics can be exported to any OpenTelemetry-compatible collector, which is how you get gateway telemetry into an existing observability platform.

The SCM dashboard covers request-level analytics. It does not replace infrastructure monitoring of the pods, nodes, cache, and load balancer, which stays your responsibility.

The paths below are relative to docs.portkey.ai.

• Cache behaviour — documented separately at self-hosting/cache-behavior, covering what is cached, for how long, and how invalidation propagates from the management plane.
• FIPS-compliant images — available for deployments with FIPS 140 obligations; see self-hosting/fips-compliant-images. Confirm availability for your entitlement and platform.
• Air-gapped — setting LOG_STORE to control_plane appears in the documentation in the context of air-gapped deployments, and the v2 log path format is explicitly unsupported in that mode. A full air-gapped deployment procedure is not published.

Platform-page chart (portkey-ai/gateway). An upgrade is a Helm upgrade against the same release and values file. Pin the chart with --version <chart-version> so the same command produces the same result on every run; helm search repo portkey-ai/gateway --versions lists what is available.

helm repo update

helm upgrade --install portkey-ai portkey-ai/gateway \
  --version <chart-version> \
  -f ./values.yaml \
  -n portkeyai

After the upgrade, confirm with helm history portkey-ai -n portkeyai and repeat the test request from After install: confirm the link. helm rollback portkey-ai <revision> -n portkeyai returns to a previous revision mechanically, but whether the data plane keeps syncing on an older chart is unpublished (see Open Questions).

SCM wizard chart (airs-gw). The command above does not apply. Use the repository and release name from the wizard's values.yaml and the upgrade instructions in the Portkey-AI/airs-gw-helm repository; the values file you downloaded at registration is the one to pass to -f. Pin, verify, and roll back the same way.

ECS and Container Apps. An upgrade is a re-apply of the same Terraform configuration with the new image tag: set the image tag variable (<IMAGE_TAG_VARIABLE>) in terraform.tfvars, run terraform plan and confirm only the task definition (ECS) or container app revision (Container Apps) changes, then terraform apply. Verify with aws ecs describe-services (runningCount equals desiredCount on the new task definition) or az containerapp revision list (new revision Active).

Cluster upgrades are separate and remain entirely yours. The managed control plane version, the node pool version, and the gateway chart version all move independently, and nothing in the product coordinates them. Supported version ranges and rollback safety are unpublished; see Open Questions.

A half-built deployment leaves a registered gateway with embedded credentials in place, and a second attempt collides with it. Remove everything in this order when you abandon an attempt or retire a gateway.

1. Uninstall the release and delete the namespace: helm uninstall <release> -n <namespace>, then kubectl delete namespace <namespace>.
2. Delete the NetworkPolicy if you created it outside the release: kubectl delete -f allow-egress.yaml (skip if the namespace deletion already removed it).
3. On the platform-page path, delete the outbound PrivateLink endpoint. If the deployment predates 2026-09-27 and built an inbound path, also delete the endpoint service, remove the allowed principal, and delete the management plane security group rule.
4. On ECS or Container Apps, run terraform destroy; on Container Apps, then recover or purge the Key Vault if you intend to reuse its name.
5. In SCM, remove the gateway entry under AI Security → AI Gateway → Admin Settings → Gateway Registration, and re-enable the SaaS row if you switched it off.
6. Empty and delete the log bucket if it is not needed for retention.

Verify: helm list -A shows no airs-gw or portkey-ai release, the Gateway Registration list no longer shows the entry, and the outbound endpoint no longer exists in the AWS console.

The path-specific groups are not interchangeable. Allowing the platform-page endpoints on a gateway installed from the SCM wizard does nothing useful, and vice versa.

Pre- and post-acquisition documentation disagree on labels, endpoints, charts, and whether the management plane ever connects inbound. On that last point the answer is now settled: it does not. When they disagree, trust in this order:

1. The tenant itself. A screenshot from a live SCM tenant beats any document. The AI Gateway deployment guide is written this way.
2. docs.paloaltonetworks.com. The Prisma AIRS administration documentation, for support statements, scale, and availability.
3. docs.portkey.ai. Detailed and largely current, and the only source for the platform-specific deployment procedures, but it carries pre-acquisition terminology and describes the portkey-ai/gateway path rather than the SCM wizard.

These are not documented anywhere in the published material. Each one changes a design decision, so get answers before committing a customer to an architecture.

• Two integration paths — are the SCM Gateway Registration path and the platform deployment pages converging, and which should a new customer be put on? They differ on chart and on endpoints, and the platform pages still document an inbound path the product does not support.
• On-premises procedure — support is confirmed for any conformant Kubernetes cluster, but no on-premises page exists. Is one planned, and is there distribution-specific guidance on storage classes and ingress that the cloud pages do not surface?
• Region and data residency — can the SCM tenant be placed in the same region as the data plane, and does hybrid satisfy EU data residency obligations?
• Upgrade lifecycle — supported Kubernetes version range, chart compatibility matrix, minimum data plane version for sync, deprecation policy, and rollback safety.
• Throughput sizing — requests per second at the published node and task sizes, how that scales with concurrency and payload size, and separate sizing for the optional Data Service and a self-hosted semantic cache.
• Air-gapped — is there a supported fully disconnected mode beyond the LOG_STORE: control_plane references? Hybrid is not it: the data plane holds a local cache and keeps serving through a management plane outage, but it still requires the outbound link. The nearest thing that exists upstream is a second chart, portkey-app, which deploys the management plane into your own environment as a licensed add-on. Ask whether Palo Alto Networks sells and supports that under Prisma AIRS, because it is a different product from the one this guide covers.
• Streaming and inspection — behaviour of streaming responses through an inspecting proxy, and any published position on TLS inspection of the management plane path.

This guide is derived from the published Prisma AIRS AI Gateway self-hosting documentation. The source pages are on docs.portkey.ai; the paths below are relative to that site.

• Architecture — self-hosting/hybrid-deployments/architecture
• Platform guides — self-hosting/hybrid-deployments/ for aws/eks, aws/ecs, aws/marketplace, azure/aks, azure/aca, and gcp
• Registration — self-hosting/hybrid-deployments/gateway-registration
• Components — product/enterprise-offering/components
• Workspaces — product/enterprise-offering/org-management/workspaces
• Operations — self-hosting/prometheus-metrics, self-hosting/cache-behavior, self-hosting/fips-compliant-images

Two Palo Alto Networks sources override the above wherever they conflict, per Which source wins when they disagree:

• Administration documentation — the Prisma AIRS administration guide on docs.paloaltonetworks.com (Configure AI Gateway), for the hybrid support statement and the scale and availability attributes.
• Tenant-verified walkthrough — Phase 2 of the AI Gateway deployment guide, for the registration wizard, the airs-gw chart, and the outbound-only connectivity model.