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

# System Description

> High level view of Onyx components

## Overview

The Onyx application is a set of Docker Containers which can be deployed on any infra and for any scale.

<Tip>
  As an open source project,
  Onyx is designed with security and data privacy as a foundational principle so that teams can trust the software even
  without needing partnership guarantees.
</Tip>

## System Architecture

<img className="rounded-image" src="https://mintcdn.com/danswer/BmiVIKl_FBXi3tRw/assets/security/OnyxArchitecture.png?fit=max&auto=format&n=BmiVIKl_FBXi3tRw&q=85&s=ff5ac8df27b2b0372535e966c45a75ec" alt="Onyx Architecture" width="2747" height="2558" data-path="assets/security/OnyxArchitecture.png" />

## Core Components

### Application Layer

* **Frontend web client**: Next.js-based web application providing the user interface for the Onyx
  platform
* **API Server**: Python FastAPI web server to handle business logic and requests
* **Background Workers**: Python workers to handle async jobs like fetching document updates, etc.

### Data Layer

* **Relational Database**: Postgres database to store application data, user sessions, and system
  state
* **Vector Database**: Vespa keyword search engine + vector store for retrieving context for queries
* **In Memory Cache**: Redis, used to optimize performance
* **File Store**: MinIO blob store for user uploaded files and documents pulled from connectors

### Infrastructure Layer

* **Request Router**: Nginx reverse proxy for load balancing and request routing

## Component Replacements

Some components of the Onyx stack are easily replaceable while others are not.

**MinIO** can be replaced with S3 or any similar object storage service.
The file store interface is abstracted to make this straightforward.

**Redis** can be replaced with a managed Redis service like AWS ElastiCache.
Other in-memory caches could work but would require code changes.

**Postgres** can be replaced with a managed Postgres service such as AWS RDS.
It is much more challenging and not advised to switch to a different relational DB due to language specific features and
optimizations.

**Vespa** can be replaced with multi-node Vespa deployment (typically not necessary) or Vespa Cloud.
Vespa is tightly integrated with the context retrieval functionalities and replacing it would require significant
development effort to maintain the same functionality.

**Nginx** can be removed and replaced with your own routing proxy.