Skip to main content
Kubernetes is the recommended production model for organizations requiring robust autoscaling, zone resilience, and platform-level operations. It is the only deployment model that offers per-workload worker isolation, queue-driven autoscaling, and geo-replication.

​
Infrastructure as Code

Deployment assets are maintained in the noxus-infra repository, which ships composed stacks for all three managed Kubernetes services. Each stack is built from reusable per-cloud modules (terraform/modules/), so you can adopt individual pieces if you already run your own networking or data services.

​
Helm Chart

The platform itself is one Helm chart, shared by all three stacks:
  • Granular Component Control: Independent configuration for Backend, Frontend, Workers, Relays, and the Agent Sandbox.
  • Advanced Scaling: HPA and KEDA-driven worker scaling.
  • Geo-replication: Additional per-zone Deployments behind a single Service.
  • Connection pooling: An optional bundled PgBouncer.

​
Helm Components

​
OpenShift

The chart renders a standard Kubernetes Ingress; it does not currently template an OpenShift Route. To run on OpenShift, either enable the cluster’s ingress-to-route controller so the Ingress is translated automatically, or create the Route objects alongside the release. Note that OpenShift’s default SCCs also restrict the added capabilities the Agent Sandbox’s syd jail requires.

​
Kubernetes Runtime Diagram

​
Autoscaling Model

​
Backend and Frontend

Standard Horizontal Pod Autoscaler (HPA) manages replicas based on CPU and memory utilization.

​
Workers

Worker pools support two advanced scaling modes:
  • Resource-based: Standard HPA for CPU/Memory.
  • Queue-driven: KEDA-powered scaling based on task queue depth, allowing for scale-to-zero and rapid bursts.

​
Advanced Worker Pool Management

The Kubernetes deployment model offers sophisticated control over how AI workloads are isolated and scaled.

​
Workspace Mapping

Worker pools can be scoped to specific workspaces so a team’s workloads run on dedicated compute:
  • workerSubscribeWorkspaces pins a pool to a comma-separated list of workspace IDs.
  • workerUnsubscribeWorkspaces excludes workspaces from a pool, so a catch-all pool can run everything else while leaving those workspaces to dedicated pools.
Used together, these give a noisy tenant its own capacity without starving the rest.
All pools in a release share the release’s namespace. Placing pools in separate namespaces — for distinct network policies or resource quotas — means installing a separate release per namespace, each with its own worker pool configuration and its own copy of the platform secrets.

​
Workload-Specific Scaling

Not all AI tasks are created equal. You can configure independent scaling policies for different pools:
  • Real-time Pools: Optimized for low-latency agent responses with higher minimum replica counts.
  • Batch Pools: Configured with KEDA to scale-to-zero when idle and burst rapidly for high-volume data processing.
  • GPU Pools: Targeted scaling for AI-intensive operations like model inference or embedding generation.

​
Secret Isolation

Security can be hardened at the pool level by injecting secrets directly into specific worker deployments. This ensures that sensitive credentials (like proprietary API keys or database strings) are only accessible to the workers that actually require them, providing robust secret isolation across your organization.

​
Typical Deployment Steps

Using the composed stacks, Terraform provisions the infrastructure and installs the chart in one apply.
1

Configure the stack

Set your domain, admin email, platform version, and Auth0 application. Worker pools and resource sizing are passed through as raw chart values via extra_values, so you get the chart’s full surface without the stack having to model every key.
2

Apply

The stack creates the cluster, data services, ingress controller, pod identity, and the Helm release. Expect 25–35 minutes on a first apply.
3

Bootstrap the database

Terraform can create the database instance but not the extensions inside it. Run this once, from inside the network:
It creates the platform’s five databases and the vector, uuid-ossp, and pg_trgm extensions.
4

Verify

Confirm the Backend reached the database and that your worker pools cover every queue type you need — a single pool on the default all_but_kb has no consumer for knowledge-base ingestion.
Terraform installs the Helm release over the Kubernetes API. If you make the API endpoint private, tofu apply must run from inside the network — a bastion, a self-hosted runner in the VPC, or over a VPN.

noxus-infra Repo

Helm chart, Terraform modules, and the operational docs set.

Sizing Guide

Instance classes, replica counts, and worker pool shapes at three scales.

Scaling Guide

HPA, KEDA, and worker pool tuning.

Agent Sandbox

Required for plugins — off by default.