Allure TestOps architecture

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

• The stateful components include:

  • 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.

• The stateless components include:

  • Allure TestOps service itself,
  • Redis in-memory database 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 production 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 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 is likely to take 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:

• Hardware for the database storage has to be SSDs only, preferably enterprise grade; HDDs will slow down the services and can become a bottleneck.
• You need to tweak the configuration of the database for proper working with SSDs as described in our manual.
• The database should never use the same disks as the artifacts storage. This will create competition for resources and eventually cripple both the database and the storage.

Object storage

The object storage is used for storing test artifacts — for example, the screenshots and videos produced during the 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:
  • AWS S3 is preferable as it shows better performance for big amount of data;
  • other options are MinIO, Ceph, etc.
• Use any CSI-compatible storage server (for Kubernetes deployments only).
• Hardware for the artifacts storage has to be SSDs only, preferably enterprise grade; HDDs will slow down the services and will become a bottleneck.
• The artifacts storage should never use the same disks as the database. This will create competition for resources and eventually cripple both the database and the storage.

Message queue

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

Session storage

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

Redis does not require a persistent storage. It uses transient memory.