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
| Requirement | Details |
|---|
| Kubernetes | Version 1.28 or later |
| Nodes | At least 3 worker nodes for fault tolerance, each with 4 vCPU and 16 GB RAM |
| Helm | Version 3, used to install and upgrade the chart |
| Gateway API | Gateway API support from the cloud provider with a Gateway controller set up |
| LoadBalancer | Capability to provision LoadBalancers for inbound traffic |
| PersistentVolumes | Capability to provision PersistentVolumes for the stateful services the chart bundles in-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.
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.
| Data store | Details |
|---|
| PostgreSQL | For example Amazon RDS, Azure Database for PostgreSQL, or self-hosted |
| MongoDB-compatible | For example MongoDB, Amazon DocumentDB, or Azure DocumentDB |
| Object storage | Any S3-protocol compatible store, for example Amazon S3, or self-hosted MinIO on clouds without a native S3 service |
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.
- 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. 
