Allure TestOps architecture

An Allure TestOps installation includes the Allure TestOps service itself and a few third-party services:

• stateful components:

  • PostgreSQL database server;
  • RabbitMQ message server;
  • S3-compatible storage server, such as Ceph or MinIO.

  For a production environment, these services must be deployed separately from the Allure TestOps service.

• stateless components:

  • Allure TestOps service itself;
  • Redis server for storing user sessions.

  These services can be deployed on the same machine. Depending on the installation method and the configuration, Redis can be deployed and pre-configured automatically.

End users should only communicate with the Allure TestOps service, optionally via a reverse proxy (see network configuration). The other components must be available to Allure TestOps over the network but must not be available directly to end users.

Hardware requirements

The optimal hardware configuration for your Allure TestOps instance depends on the workload. For a small project, we recommend starting with 4 vCPU and 8 GB of RAM and scale up as needed.

Storage requirements

Databases

Allure TestOps relies on PostgreSQL as the main data storage. The minimal supported version is PostgreSQL 15.

The required disk space depends entirely on the amount of test results that you are going to process with your Allure TestOps instance. A project with 100 000 tests will take up about 300 GB in the database after 1 year of daily runs.

For acceptable performance of the whole system when processing test results from automated tests, especially if your test base is big and runs occur several times a day, you need to meet the following requirements:

• Use only SSDs as the database storage, preferably enterprise-grade. HDDs will slow down the services.
• Configure the database correctly for proper SSD performance, as described in our manual.
• The database should not be stored on the same disk as the artifact storage. This will create resource contention and ultimately slow down both the database and the storage.

Object storage

The object storage is used to store test result artifacts and test cases (for example, screenshots and videos produced during test runs). The volume of such artifacts depends on the tests that you will be running. For a small project, we recommend to start with at least 50 GB of disk space and then scale up as needed.

For acceptable performance of the whole system for the processing of the test artifacts from automated tests, you need to meet the following requirements:

• Use any S3-compatible storage server:
  • Amazon S3 is preferable as it shows better performance for big amount of data.
  • Other options are MinIO, Ceph, etc.
• If you use Kubernetes, use a CSI-compatible storage.
• Use only SSDs as the data storage for artifact storage, preferably enterprise-grade. HDDs will slow down the services.
• Artifact storage should not be stored on the same disk as the database. This will create resource contention and ultimately slow down both the database and the storage.

Message queue

A RabbitMQ message queue server is used internally by Allure TestOps.

Session storage

A Redis server is used for storing user authentication sessions by Allure TestOps.

Redis does not require persistent storage since it operates using RAM.