> ## Documentation Index
> Fetch the complete documentation index at: https://docs.noxus.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> Noxus runtime architecture for on-premise or on-cloud deployments

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:

```mermaid theme={null}
flowchart TB
  subgraph Edge[Public Edge]
    DNS[DNS]
    IN[Ingress / Reverse Proxy]
  end

  subgraph App[Noxus Application]
    FE[Noxus Frontend]
    BE[Noxus Backend]
    RE[Noxus Relays]
    W[Noxus Workers]
  end

  subgraph Data[Data Services]
    PG[(PostgreSQL + pgvector)]
    RD[(Redis)]
    CS[(Cold Storage)]
  end

  subgraph Obs[Observability]
    PM[Prometheus]
    OT[OpenTelemetry Collector]
    LG[Central Logs]
  end

  DNS --> IN
  IN --> FE
  IN --> BE
  IN --> RE

  FE --> BE
  BE --> PG
  BE --> RD
  BE --> CS

  W --> PG
  W --> RD
  W --> CS
  RE --> PG
  RE --> RD

  FE -.metrics.-> PM
  BE -.metrics.-> PM
  W -.metrics.-> PM
  RE -.metrics.-> PM

  BE -.traces.-> OT
  W -.traces.-> OT
  RE -.traces.-> OT

  FE -.logs.-> LG
  BE -.logs.-> LG
  W -.logs.-> LG
  RE -.logs.-> LG
```

## Core Noxus Components

<AccordionGroup>
  <Accordion title="Noxus Frontend">
    Next.js application that serves the user interface and talks to Noxus
    Backend over API/WebSocket.
  </Accordion>

  <Accordion title="Noxus Backend">
    API/control plane for workflows, auth, configuration, integrations, and
    orchestration.
  </Accordion>

  <Accordion title="Noxus Workers">
    Async execution plane for runs. In Kubernetes, workers are pool-based
    (`worker.pools`) with HPA or KEDA autoscaling.
  </Accordion>

  <Accordion title="Noxus Relays">
    Optional integration webhook/event handlers (for external events and relay
    endpoints).
  </Accordion>
</AccordionGroup>

## 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)

<CardGroup cols={2}>
  <Card title="Deployment Overview" icon="compass" href="/deployment/overview">
    Entry point to deployment models, config, security, and operations
  </Card>

  <Card title="Kubernetes" icon="square-stack" href="/deployment/kubernetes/overview">
    Helm-based architecture with worker pools, KEDA, and ingress
  </Card>
</CardGroup>