Skip to main content
Feature available with the Enterprise Plan Orq.ai deploys on-premise as a single Helm chart into a Kubernetes cluster, on any cloud provider (AWS, Azure, GCP) or self-managed infrastructure. All components run inside the customer environment, and the platform can operate fully air-gapped once the container images are downloaded or cached in a local registry. In that mode the configured model endpoints must sit inside the isolated environment.

​
Kubernetes cluster

This sizing runs the complete platform, including the supporting services the chart deploys in-cluster. A sandbox or development environment running only the AI Gateway can use smaller worker nodes. For larger traffic, the platform scales automatically when more hardware is available.
Tolerations, node selectors, and affinity are configurable globally and per service, along with extra pod annotations, so workloads can be placed on dedicated node groups.

​
External data stores

The platform connects to three customer-operated data stores. External means external to the Orq.ai Helm chart: the chart does not deploy them. They can be managed cloud services, run in the same VPC, or even be deployed into the same Kubernetes cluster. The data stores stay customer-operated by design. All persistent data remains in stores the customer fully controls, existing backup and disaster recovery policies apply unchanged, compliance controls such as encryption at rest and key management are reused as is, and the data outlives the platform: uninstalling Orq.ai leaves every store intact.

​
Network and access

  • DNS and TLS: a DNS record and TLS certificate for the platform hostname, terminated at the Gateway or an upstream load balancer.
  • License: an Orq.ai-issued license key, provided during onboarding.
  • Secrets: every credential the chart needs, including the license, can be set as a Helm value or referenced from a pre-created Kubernetes Secret, so secrets can be managed by an external secrets operator.
  • Container registry: outbound access to ghcr.io with credentials issued by Orq.ai, or mirror the images into a private registry. Once images are cached, no further registry access is needed.
  • Database access: the data stores must accept connections from the cluster, either by allowlisting the cluster’s egress IP or private endpoint, or by running in the same VPC or network.
  • Object storage access: the object store must be reachable from end-user browsers over trusted HTTPS for file uploads and downloads.

​
Isolated environments

Environments can run as fully separate Orq.ai installs. Each install is a complete platform instance, and the chart installs as many times as there are environments, typically one per stage: develop, staging, and production. Separate installs are the hard-isolation option. Environments tag Agent and Evaluator versions within a single install instead. Each install has its own:
  • Kubernetes cluster or namespace
  • PostgreSQL, MongoDB-compatible store, and object storage
  • Hostname, TLS certificate, and Gateway route
  • Secrets and API keys
  • Workspaces, identities, knowledge base data, memory stores, and traces
  • SSO configuration and network policy
Each install holds its own data stores, secrets, and traffic path, so no data, credential, or request crosses from one environment to another.

​
Licensing

The license is a signed JWT that every service validates offline against embedded keys, with no phone-home, so one license key validates on every install of the same customer. Confirm the terms that apply to non-production installs with an Orq.ai account manager.

​
Sizing

An install that runs only the AI Gateway can use the smaller worker nodes described in Kubernetes cluster. A non-production install running the full platform uses the standard sizing.

​
Upgrades

Each install is a separate Helm release, so every environment upgrades on its own schedule, for example moving staging to a new chart version ahead of production. Database and data migrations run during the upgrade through the chart’s Helm hooks, so migration timing is part of each environment’s own upgrade rather than a cluster-wide step. Confirm with Orq.ai whether two installs that promote to one another can sit on different chart versions.

​
Promotion

Prompts, Agents, Evaluators, and datasets move between installs through the API, the Orq CLI, or the SDKs: read the entity from the source install and write it to the target install. Each install answers on its own hostname, so point each call at the install it belongs to with the global --server flag or one saved profile per install.
Promote the resources a promoted entity depends on first, so the models, knowledge bases, and prompts it references exist on the target install. Deployments are created in AI Studio or over MCP on each install, so recreate a Deployment in the target environment against the promoted Prompt or Agent. The API and CLI cover invoking, streaming, and reading a Deployment’s configuration. The chart is compatible with GitOps tools such as ArgoCD, so cluster configuration promotes through the same repository and review process as the rest of the deployment.

​
Cluster topology

An install runs in its own Kubernetes cluster, or shares a cluster with other installs. On a shared cluster, each install is a separate Helm release, and each cluster-scoped resource is shared by every install in that cluster:
  • Gateway API: the CRDs and the Gateway controller.
  • Agent sandbox: the CRDs, the controller, and the agent-sandbox-system and agent-sandbox namespaces, when the agent sandbox is installed.
Confirm the supported arrangement, including whether a shared cluster supports one namespace per install, with Orq.ai before planning a shared cluster.

​
Connecting SDKs and clients

SDKs, OpenAI-compatible clients, and OpenTelemetry exporters default to the managed cloud at https://my.orq.ai. Point them at the platform hostname instead. See Base URLs for the setting each client uses. For deployment assistance or enterprise pricing, contact support@orq.ai or reach out to an Orq.ai account manager.