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, as long as the configured model endpoints are reachable from within the 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.
For deployment assistance or enterprise pricing, contact support@orq.ai or reach out to an Orq.ai account manager.