Skip to main content
Noxus has a flexible runtime topology that is kept consistent on the different deployment methods, based on a few key services. The following graph provides a quick overview of this topology:

​
Core Noxus Components

Next.js application that serves the user interface and talks to Noxus Backend over API/WebSocket.
API/control plane for workflows, auth, configuration, integrations, and orchestration.
Async execution plane for runs. In Kubernetes, workers are pool-based (worker.pools) with HPA or KEDA autoscaling.
Scheduled task service. Runs as a single scheduler instance.
Optional integration webhook/event handlers (for external events and relay endpoints).

​
Data Layers

  • PostgreSQL: storage layer for domain entities, analytics and platform audit logs
  • Redis: cache system
  • Cold Storage: object/file persistence (s3, gcloud, minio, local-compatible options).
Message passing and queueing / broker happens either through PostgreSQL or Redis depending on platform configurations

​
Traffic And Domains

The platform default ingress model uses three entrypoints for the platform. As an example:
  • <domain> -> Noxus Frontend
  • api.<domain> -> Noxus Backend
  • relay.<domain> -> Noxus Relays (if enabled)
These however can be mapped differently, in case of limitations such as:
  • <domain> -> Noxus Frontend
  • <domain>/api/backend -> Noxus Backend
  • <domain>/relays -> Noxus Relays (if enabled)

Deployment Overview

Entry point to deployment models, config, security, and operations

Kubernetes

Helm-based architecture with worker pools, KEDA, and ingress