S3-compatible storage

Allure TestOps uses object storage for artifacts that sit alongside the database-backed execution data. Use this page when you are planning external artifact storage for a self-hosted deployment, choosing a storage class, or migrating artifact data away from a demo-style local setup.

When this guidance matters

This page is most relevant when:

you are deploying a production self-hosted instance;
you want artifacts stored outside the local Docker or host filesystem;
you need an object-storage service that can sustain frequent access to test artifacts.

Storage requirements

Separate the storage from the database disk

Do not place object-storage data and PostgreSQL data on the same disk. Keeping them separate avoids I/O contention between artifact access and database work.

Use SSD-backed storage

Use SSD-backed storage for production object storage. Artifact access patterns become slower and less predictable on HDD-backed storage as the installation grows.

Choose a frequent-access storage class

Use a standard storage class intended for regular reads and writes. Avoid cold or archival tiers for active TestOps artifact storage because they increase latency and can degrade the user-facing experience.

Kubernetes note

If you use Kubernetes, connect the storage through the provider-supported CSI driver or the supported storage integration method for your environment.

Supported storage patterns

The most common production choices are:

Amazon S3;
MinIO;
Google Cloud Storage configured for the required compatibility path;
another S3-compatible object-storage service your platform team supports.

Amazon S3 policy example

For Amazon S3, the storage identity needs bucket-listing and object read/write/delete access.

Example policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3assets",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:ListBucket",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::<ALLURE_S3_BUCKET_NAME>/*",
        "arn:aws:s3:::<ALLURE_S3_BUCKET_NAME>"
      ]
    }
  ]
}

Google Cloud Storage note

For Google Cloud Storage, use a bucket configuration that supports the access model required by your environment, and use https://storage.googleapis.com as the service URL in the TestOps configuration.

Migrate data to a dedicated MinIO or S3-compatible target

If you started from a Docker Compose demo deployment or another local-storage setup, migrate the stored artifact objects before you treat the instance as a production deployment.

Do not bulk-copy the object files by hand. Use the object-storage tooling so the target storage keeps the correct metadata and access semantics.

Migration outline

Bring up the target object-storage service and confirm that it is reachable.
Add connection values for the target storage to the environment:
- TESTOPS_S3_URL_NEW
- TESTOPS_S3_BUCKET_NEW
- TESTOPS_S3_ACCESS_KEY_NEW
- TESTOPS_S3_SECRET_KEY_NEW
Add a one-off migration service that can copy the existing object tree into the new target.

Example service block:

services:
  minio-migrate:
    restart: "no"
    image: minio/mc
    container_name: minio-migrate
    depends_on:
      - minio-local
    networks:
      - testops-net
    entrypoint: "/bin/sh -c"
    command: >
      "mc config host add minio-old ${DEMO_INSTANCE_S3_URL} ${DEMO_INSTANCE_S3_ACCESS_KEY} ${DEMO_INSTANCE_S3_SECRET_KEY} --api S3v4 &&
       mc config host add s3-new ${TESTOPS_S3_URL_NEW} ${TESTOPS_S3_ACCESS_KEY_NEW} ${TESTOPS_S3_SECRET_KEY_NEW} --api S3v4 &&
      mc cp -r minio-old/${DEMO_INSTANCE_S3_BUCKET}/v2 s3-new/${TESTOPS_S3_BUCKET_NEW}/"

The example copies the v2 object prefix used by the application. Keep that path layout intact in the target bucket so existing artifact references still resolve after the cutover.

Run the migration job:

docker compose run minio-migrate

Verify the storage path

After configuration or migration:

Upload or generate a launch with attachments or result artifacts.
Confirm that the launch opens correctly in TestOps.
Confirm that the object-storage bucket contains the expected artifact data.
If you migrated existing data, open older launches and verify that their artifacts still load.

Install Allure TestOps for shared self-hosted prerequisites.
Architecture and planning for the broader storage topology.
Storage maintenance for operational storage cleanup and retention work.