# System requirements for BRIX On-Premises 

> [HTML Version](elma365-enterprise-on-premises.html)

The article shows the minimum system requirements for correct BRIX On-Premises installation. The information provided below is not a guide for server configuration. Use it only to estimate the compatibility of your company’s equipment with the BRIX software. The actual parameters may vary greatly depending on the workload profile and are selected according to customer requirements.

````
начало внимание

````
In this article, the term **User** means a BRIX account. In licensing terms, it can be a [named](licences.md#namedlicense) or a [floating](licences.md#floatinglicense) license or an integration with an external system.

````
конец внимание

````


## BRIX server

The table below lists software and hardware requirements for the BRIX server installation.

| | |
|------|------|
| **Operating System\*** | Linux x64<br>**Recommended:**<br>Ubuntu Server 22.04 <br>Debian 11<br>**Supported:**<br>Ubuntu Server 22.04<br>Debian 10<br>Astra Linux Special Edition 1.7 (Open)\*\*<br>RED OS 7, 8\*\* |
| **Kubernetes**\* | Supported:<br>Kubernetes API v. 2 (Kubernetes 1.21–1.33 version) |
| **Deckhouse** | Deckhouse 1.69\*\*\* and higher |
| **Helm** | Helm v. 3.14.0 and higher |
| **Minimum hardware requirements for BRIX** **On-Premises Standard  (maximum 200 licenses)**\*\*\*\*  | CPU: x86-64, 8 or more vCPUs.<br>Hard drive\*\*\*\*\*: 100 GB, write IOPS 1000 or more.<br>RAM: 12 GB or more.<br>Internet connection: LAN 100 Mbit/sec or above.<br>MongoDB 5.0+ requires using the AVX instruction set. |
| **Minimum hardware requirements for BRIX On-Premises Enterprise (for 500 users)**\*\*\*\* | **Application server**<br>CPU: x86-64, 8 or more vCPUs.<br>Hard drive\*\*\*\*\*:  100 GB, write IOPS 2000 or more.<br>RAM: 16 GB or more.<br>Internet connection: LAN 1 Gbit/sec or faster.<br>If the demand for server resources and the number of simultaneously connected users increases:<br>- The number of processor cores has to be increased.<br>- The amount of RAM has to be increased.<br>- The system needs to be scaled by adding more servers.<br>One application instance can support up to 10,000 users (if the number of CPU cores and the amount of RAM are proportionally increased). However, system operation under such load is not recommended. This information is provided only to help you estimate a workload limit when designing your local IT infrastructure.<br>When planning the server upgrade under moderate workload, the following approach to hardware sizing is optimal:<br>RAM: +8 GB for each additional 500 users.<br>CPU: +4 cores for each additional 500 users.<br>The number of floating license users is estimated by the client or determined by analyzing the company’s operations.<br>When enabling auto-scaling services stick to limits and requests required by the system. |


\* When installing BRIX on Deckhouse platform, see supported operating system and Kubernetes versions in the [official documentation](https://deckhouse.io/products/kubernetes-platform/documentation/v1/supported_versions.html).

\*\* Vendor technical support is required.

\*\*\* If using Deckhouse on a Linux distribution other than Ubuntu or Debian, or in an offline environment, vendor technical support is required.

\*\*\*\* A backup system must be located on a separate server. The storage capacity is calculated based on the number and size of backup copies.

\*\*\*\*\* When installed to a cluster, the application’s performance and stability largely depend on the hard drive’s speed. A slow hard drive increases the request latency in the cluster and can cause it to become unstable. Read more about checking a hard drive’s performance in [Test the hard drive’s performance](disk-performance.md).

If you use hypervisors, for correct operation of Kubernetes nodes and BRIX, you need to allocate a fixed amount of RAM in the virtual machine’s settings. This amount must meet the system requirements above.

It is not recommended to use dynamic memory allocation (shared memory or “from X GB to Y GB”). Virtual machines with dynamically allocated memory operate more slowly, and the hypervisor responds incorrectly to OS memory requirements.

## Data storage server

The table below lists software and hardware requirements for installing data storing and processing servers of the BRIX system.

### PostgreSQL



| | |
|------|------|
| **Minimum hardware requirements (for 500 users)\*** | **PostgreSQL database server**<br>The server stores main system data: users, app items, settings of workspaces and apps, business processes, pages, widgets, tasks, events, and other configurations.<br>DBMS: PostgreSQL v13–18.<br>CPU: x86-64, 4 or more vCPUs.<br>Hard drive: 100 GB, write IOPS 2000 or more.<br>RAM: 8 GB or more.<br>Internet connection: LAN 1 Gbit/sec or faster.<br>If the demand for server resources and the number of simultaneously connected users increases:<br>- The number of processor cores has to be increased.<br>- The amount of RAM has to be increased.<br>- The data storage capacity has to be increased.<br>When planning the server upgrade under moderate workload, the following approach to hardware sizing is optimal:<br>RAM: +4 GB for each additional 500 users.<br>CPU: +2 cores for each additional 500 users.<br>The required increase in disk storage capacity is estimated by the client or determined by analyzing the company’s operations. |




### MongoDB



| | |
|------|------|
| **Minimum hardware requirements (for 500 users)\*** | **MongoDB database server**<br>The server stores unstructured system settings and data from live chats and activity streams.<br>You can disable MongoDB during the initial installation of the system, starting with version 2026.2. This will cause data to be stored in PostgreSQL. For more information, read [Modify BRIX parameters](change-settings-enterprise.md#without-mongodb).<br>DBMS: MongoDB v3.8–8.0.<br>CPU: x86-64, 4 or more vCPUs. MongoDB 5.0+ requires using the AVX instruction set.<br>Hard drive: 50 GB, write IOPS 2000 or more.<br>RAM: 8 GB or more.<br>Internet connection: LAN 1 Gbit/sec or faster.<br>If the demand for server resources and the number of simultaneously connected users increases:<br>- The number of processor cores has to be increased.<br>- The amount of RAM has to be increased.<br>- The data storage capacity has to be increased.<br>When planning the server upgrade under moderate workload, the following approach to hardware sizing is optimal:<br>RAM: +4 GB for each additional 500 users.<br>CPU: +2 cores for each additional 500 users.<br>The required increase in disk storage capacity is estimated by the client or determined by analyzing the company’s operations. |




### RabbitMQ

| | |
|------|------|
| **Minimum hardware requirements (for 500 users)\*** | **RabbitMQ event bus server**<br>The server provides task queues among services. It doesn’t store data permanently.<br>MQ: RabbitMQ v3.9.15-3.13.<br>CPU: x86-64, 4 or more vCPUs.<br>Hard drive: 40 GB, write IOPS 2000 or more.<br>RAM: 8 GB or more.<br>Internet connection: LAN 1 Gbit/sec or faster.<br>If the demand for server resources and the number of simultaneously connected users increases:<br>- The number of processor cores has to be increased.<br>- The amount of RAM has to be increased.<br>When planning the server upgrade under moderate workload, the following approach to hardware sizing is optimal:<br>RAM: +4 GB for each additional 500 users.<br>CPU: +2 cores for each additional 500 users.<br>The required increase in disk storage capacity is estimated by the client or determined by analyzing the company’s operations. |




### Valkey/Redis



| | |
|------|------|
| **Minimum hardware requirements (for 500 users)\*** | **Valkey or Redis cache server**<br>The server is used for caching processed information. It doesn’t store data permanently.<br>Cache: Valkey 7.2.8 or higher, Redis v5.0 or v6.2.<br>CPU: x86-64, 2 or more vCPUs.<br>Hard drive: 50 GB, write IOPS 2000 or more.<br>RAM: 4 GB or more.<br>Internet connection: LAN 1 Gbit/sec or faster.<br>If the demand for server resources and the number of simultaneously connected users increases:<br>- The number of processor cores has to be increased.<br>- The amount of RAM has to be increased.<br>When planning the server upgrade under moderate workload, the following approach to hardware sizing is optimal:<br>RAM: +4 GB for each additional 500 users.<br>CPU: +2 cores for each additional 500 users. |




### S3



| | |
|------|------|
| **Minimum hardware requirements (for 500 users)\*** | **S3 object storage server**<br>You can use any S3-compatible object storage software.<br>We recommend using SeaweedFS as your S3 storage solution, as MinIO has been transitioned to limited support mode since December, 2025. For more information, please see the [official MinIO information](https://github.com/minio/minio/commit/27742d469462e1561c776f88ca7a1f26816d69e2).<br>S3: <br>- SeaweedFS v4 and higher.<br>- Minio S3 v2022.8.8 and higher.<br>For more information on configuring S3 servers, see the following articles:<br>- [SeaweedFS](seaweedfs.md).<br>- [MinIO (S3)](configure-minio.md).<br><br>CPU: x86-64, 2 or more vCPUs.<br>Hard drive: 100 GB, write IOPS 2000 or more.<br>RAM: 2 GB or more.<br>Internet connection: LAN 1 Gbit/sec or faster.<br>If the demand for file download and file generation increases:<br>- Disk storage space needs to be increased.<br>- The system needs to be scaled by adding more servers.<br>When the number of file download and file generation operations increases on the server, the following approach to hardware sizing is optimal:<br>RAM: +2 GB for each additional 1,000 users.<br>CPU: +1 core for each additional 1,000 users.<br>The required increase in disk storage capacity is estimated by the client or determined by analyzing the company’s operations. |




\* A backup system must be located on a separate server. The storage capacity is calculated based on the number and size of backup copies.

## Minimum hardware requirements for different number of users

The tables below show BRIX On-Premises Kubernetes hardware requirements for 500, 1,000, 2,000, 5,000, and 10,000 users. The term **user** here is used to reference a person or an external automated system that has an account and a permission to work with BRIX.

The actual parameters may vary depending on the real use scenarios and the application of the system in your company.

### 500 users

| | | | |
|------|------|------|------|
| **500 users** | | | 
| **Service** | [vCPUs](#vcpu)**\*** | **RAM, GB** | [SSD](#ssd)**, GB\*\*** |
| BRIX server | 8 | 16 | 100 |
| PostgreSQL server | 4 | 8 | 100 |
| MongoDB server | 4 | 8 | 50 |
| RabbitMQ server | 4 | 8 | 40 |
| Valkey/Redis server | 2 | 4 | 50 |
| S3 server | 2 | 2 | 100 |
| HAProxy server | 2 | 2 | 30 |
| **Total** | **26** | **48** | **470** |


### 1,000 users

| | | | |
|------|------|------|------|
| **1,000 users** | | | 
| **Service** | [vCPUs](#vcpu)**\*** | **RAM, GB** | [SSD](#ssd)**,** **GB\*\*** |
| BRIX server | 12 | 16 | 100 |
| PostgreSQL server | 6 | 12 | 100 |
| MongoDB server | 4 | 8 | 50 |
| RabbitMQ server | 4 | 8 | 40 |
| Valkey/Redis server | 2 | 4 | 50 |
| S3 server | 2 | 2 | 100 |
| HAProxy server | 2 | 2 | 30 |
| **Total** | **32** | **52** | **470** |


### 2,000 users

| | | | |
|------|------|------|------|
| **2,000 users** | | | 
| **Service** | [vCPUs](#vcpu)**\*** | **RAM, GB** | [SSD](#ssd)**, GB\*\*** |
| BRIX server | 16 | 24 | 100 |
| PostgreSQL server | 8 | 16 | 100 |
| MongoDB server | 6 | 8 | 50 |
| RabbitMQ server | 4 | 8 | 40 |
| Valkey/Redis server | 2 | 8 | 50 |
| S3 server | 2 | 4 | 100 |
| HAProxy server | 2 | 2 | 30 |
| **Total** | **40** | **70** | **470** |


### 5,000 users

| | | | |
|------|------|------|------|
| **5,000 users** | | | 
| **Service** | [vCPUs](#vcpu)**\*** | **RAM, GB** | [SSD](#ssd)**, GB\*\*** |
| BRIX server | 16 | 32 | 100 |
| PostgreSQL server (primary) | 4 | 16 | 200 |
| PostgreSQL server (subordinate) | 4 | 16 | 200 |
| PostgreSQL server (subordinate) | 4 | 16 | 200 |
| MongoDB server (primary) | 2 | 8 | 100 |
| MongoDB server (subordinate) | 2 | 8 | 100 |
| MongoDB server (subordinate) | 2 | 8 | 100 |
| RabbitMQ server | 4 | 8 | 40 |
| Valkey/Redis server | 2 | 8 | 50 |
| S3 server | 2 | 8 | 200 |
| HAProxy server | 2 | 2 | 30 |
| **Total** | **44** | **130** | **1,320** |


### 10,000 users

| | | | |
|------|------|------|------|
| **10,000 users** | | | 
| **Service** | [vCPUs](#vcpu)**\*** | **RAM, GB** | [SSD](#ssd)**, GB\*\*** |
| BRIX server | 32 | 64 | 100 |
| PostgreSQL server (primary) | 8 | 32 | 250 |
| PostgreSQL server (subordinate) | 8 | 32 | 250 |
| PostgreSQL server (subordinate) | 8 | 32 | 250 |
| MongoDB server (primary) | 2 | 8 | 200 |
| MongoDB server (subordinate) | 2 | 8 | 200 |
| MongoDB server (subordinate) | 2 | 8 | 200 |
| RabbitMQ server | 4 | 8 | 40 |
| Valkey/Redis server | 2 | 8 | 50 |
| S3 server | 2 | 8 | 500 |
| HAProxy server | 2 | 2 | 30 |
| **Total** | **72** | **210** | **2,070** |


****\* A vCPU is a hyperthreading core of the physical CPU. For cloud providers, it is a vCPU or vCore.

****\*\* The SSD space that needs to be provided directly depends on the needs of your company. It is determined individually for each service in the system depending on the amount of data that is supposed to be stored in them.

To determine the exact system requirements for your configuration or receive information on hardware requirements for 10,000+ users, please contact our sales reps at** info@brix24.com**.

### Fault-tolerant server architecture

To build a fault-tolerant architecture and optimize server load balancing, it is possible to deploy multiple servers in a cluster. The application server and the data storage and processing servers are scaled independently.

## BRIX cluster

The cluster provides load balancing for applications, as well as replication and scaling of internal services. This allows setting up a fault-tolerant solution that can survive the failure of one server. For seamless servers connectivity, a [ready-made solution](https://kubernetes.io/) is used.

You need to have at least **three** **servers** to set up the cluster.

## PostgreSQL cluster

PostgreSQL cluster is formed by a primary server and replica(s). One server becomes the main one and sends its data to the other servers. You can read more about setting up and operating the cluster in [PostgreSQL official documentation](https://www.postgresql.org/docs/15/high-availability.html).

You need at least **two servers** to set up the cluster.



## MongoDB cluster

Several servers are seamlessly combined into a fault-tolerant cluster providing data replication and redistribution. For more details, see [MongoDB official documentation](https://docs.mongodb.com/v3.6/reference/glossary/#term-high-availability).

You need at least **three** **servers** to set up the cluster.



## RabbitMQ cluster

Several servers combined into a cluster balance message processing and delivery. For more details, see [RabbitMQ official documentation](https://www.rabbitmq.com/clustering.html).

You need at least **three** **servers** to set up the cluster.



## Valkey or Redis cluster

Several servers are joined into a primary/replica cluster. One server becomes the main one and sends its data to the other servers. For more details, see [Valkey official documentation](https://valkey.io/topics/sentinel/) or [Redis official documentation](https://redis.io/topics/sentinel).

You need at least **three** **servers** to set up the cluster.



## MinIO S3 cluster

Several servers are joined into a fault-tolerant cluster providing data replication and redistribution. For more details, see [MinIO official documentation](https://docs.min.io/docs/distributed-minio-quickstart-guide.html).

You need at least **four** **servers** to set up a cluster.