Desplegando almacenamiento autohospedado en Cloudflare Workers Allure 3

Ejecuta Allure Report Storage como un Cloudflare Worker, respaldado por Cloudflare D1 (metadatos) y R2 (archivos de reporte).

1. Crea los recursos de Cloudflare.
2. Configura los secretos.
3. Despliega.
4. Valida que está ejecutándose.
5. Usa almacenamiento compatible con S3 en lugar de R2 (opcional).

Requisitos

• Una cuenta de Cloudflare
• wrangler, la CLI de Cloudflare

1. Crea los recursos de Cloudflare

Crea la base de datos D1 y el bucket R2:

corepack enable
yarn dlx wrangler d1 create allure-report-storage
yarn dlx wrangler r2 bucket create allure-report-storage

Actualiza wrangler.toml con el database_id que imprime el primer comando. El nombre del bucket R2 debe coincidir con bucket_name en wrangler.toml (allure-report-storage por defecto) o actualizarse allí.

2. Configura los secretos

yarn dlx wrangler secret put ACCESS_TOKEN
yarn dlx wrangler secret put SECRET

Ambos son cadenas simples que eliges tú mismo cuando se te solicite, no un valor generado ni de formato fijo; elige algo largo y difícil de adivinar. Su uso es limitado: ACCESS_TOKEN solo autoriza la generación de un token de acceso al reporte (POST /api/token) y el establecimiento de la rama principal de un proyecto, nada más; SECRET nunca se envía a ningún lado, solo firma los tokens de acceso al reporte emitidos desde esas solicitudes de ACCESS_TOKEN. Ninguno es el que entregas directamente a Allure 3 — ese es un token ars1.<payload>.<signature> recién generado, explicado en Conectando Allure 3 al servicio de almacenamiento.

3. Despliega

corepack enable
yarn dlx wrangler deploy

O ejecútalo localmente primero, completamente en tu propia máquina. wrangler dev emula D1 y R2 localmente, sin tocar recursos reales de Cloudflare:

yarn dlx wrangler dev

4. Valida que está ejecutándose

curl https://<tu-dominio-worker>/api/ping

Una respuesta {"pong":true,...} confirma que el servicio está activo. Desde aquí, conecta Allure 3 al servicio de almacenamiento.

5. Usa almacenamiento compatible con S3 en lugar de R2

Establece STORAGE_BACKEND=s3 (como variable o secreto de Worker, igual que ACCESS_TOKEN/SECRET) para almacenar archivos de reporte en un bucket compatible con S3 en lugar del binding nativo de R2.

Variable	Obligatorio	Propósito
S3_BUCKET	Sí	Nombre del bucket
S3_REGION	Sí	Región del bucket (auto para Cloudflare R2)
S3_ENDPOINT	Sí	URL del endpoint compatible con S3
S3_ACCESS_KEY_ID	No*	Access key
S3_SECRET_ACCESS_KEY	No*	Secret key
S3_FORCE_PATH_STYLE	Sí	true para la mayoría de servidores S3 autohospedados (por ejemplo, MinIO), false para R2
S3_SESSION_TOKEN	No	Token de sesión, para credenciales temporales
S3_PREFIX	No	Prefijo aplicado a cada clave de objeto
S3_REPORTS_PREFIX	No	Prefijo para archivos de reporte (por defecto files)
S3_ASSETS_PREFIX	No	Prefijo para assets compartidos (por defecto assets)

* Si se omite, se utiliza la cadena de proveedores de credenciales predeterminada del SDK de AWS.

yarn dlx wrangler secret put STORAGE_BACKEND
yarn dlx wrangler secret put S3_BUCKET
yarn dlx wrangler secret put S3_REGION
yarn dlx wrangler secret put S3_ENDPOINT
yarn dlx wrangler secret put S3_ACCESS_KEY_ID
yarn dlx wrangler secret put S3_SECRET_ACCESS_KEY
yarn dlx wrangler secret put S3_FORCE_PATH_STYLE

Valores de ejemplo para Cloudflare R2:

STORAGE_BACKEND=s3
S3_BUCKET=allure-report-storage
S3_REGION=auto
S3_ENDPOINT=https://<cloudflare-account-id>.r2.cloudflarestorage.com
S3_ACCESS_KEY_ID=<access-key>
S3_SECRET_ACCESS_KEY=<secret-key>
S3_FORCE_PATH_STYLE=false

Los endpoints específicos de bucket de R2 (<bucket>.<account-id>.r2.cloudflarestorage.com) se normalizan internamente a la forma a nivel de cuenta mostrada arriba.

Consulta Almacenamiento autohospedado para saber cómo usarlo: publicación, ramas, historial y eliminación de reportes.