---
title: "La capa web en Cloudflare Workers"
description: "Ejecuta una versión reducida de la capa web de Quire en Cloudflare Workers."
image: "https://docs.quirelms.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.quirelms.com/es-419/llms.txt
> Use this file to discover all available pages before exploring further.

# La capa web en Cloudflare Workers

<span id="the-web-tier-on-cloudflare-workers"></span>

El diseño se describe en la sección 6 de `docs/architecture/23-ops.md`. Workers ejecuta una capa web reducida. La paridad de funciones en Workers queda fuera del alcance (sección 12 del PRD): al iniciar, se rechazan por nombre las funciones que este destino no puede realizar.

## Estado de esta versión <!--quire:status-in-this-release-->

La configuración está lista (`apps/web/wrangler.jsonc`, el preajuste Nitro `cloudflare-module`, el puente Hyperdrive y las comprobaciones de inicio). Un Worker requiere almacenamiento compatible con S3 para R2 (`QUIRE_STORAGE_DRIVER=s3`), un controlador de tiempo real entre solicitudes (`QUIRE_REALTIME_DRIVER=durable_objects` o `centrifugo`), una caché compartida (`QUIRE_CACHE_DRIVER=postgres` o `valkey`) y un proveedor de correo HTTP. Sin estos, el Worker se niega a iniciar y sus registros indican cada configuración faltante. El controlador Durable Objects es cliente del Worker en tiempo real de `apps/realtime-worker` (un Durable Object por canal para distribuir eventos, manejar presencia e historial; y uno por persona para desconexiones); despliégalo junto con este, como se indica abajo, o usa Centrifugo.

## Componentes <!--quire:the-pieces-->

| Componente | En Cloudflare |
| --- | --- |
| `web` | Un Worker con `nodejs_compat` |
| Postgres | Externa, accesible mediante Hyperdrive: `HYPERDRIVE` para el rol de aplicación y `REPORT_HYPERDRIVE` para el rol de informes en esa misma base física. Al iniciar, la capa web copia cada cadena de conexión en `DATABASE_URL` y `QUIRE_REPORT_DATABASE_URL` |
| Archivos | R2, mediante su API de S3 (`S3_ENDPOINT=https://<account>.r2.cloudflarestorage.com`); el binding `FILES` conecta el bucket |
| Tareas en segundo plano | pg-boss mediante Hyperdrive cuando la tarea debe agregarse junto con una escritura. Con `QUIRE_QUEUE_DRIVER=cloudflare` en el worker complementario, las tareas ligeras (entregas de notificaciones y webhooks sin orden definido) pasan por Cloudflare Queues y no se consulta Postgres para ellas. El worker complementario ejecuta ambas opciones |
| Tiempo real | Worker en tiempo real `apps/realtime-worker`, con Durable Objects |
| `worker`, `scheduler`, `collab`, `content`, ClamAV, Gotenberg y ffmpeg | Host de contenedores complementario. Un Worker no puede ejecutarlos |
| Trazas | Observabilidad de Workers, activada en `wrangler.jsonc` |

`REPORT_HYPERDRIVE` proporciona el rol de informes para la base física indicada por `HYPERDRIVE`. Este destino no atiende a tenants fijados a otras bases físicas, como se explica abajo.

## Limitaciones de este destino <!--quire:what-this-target-cannot-do-->

Al iniciar, se rechaza la configuración y se enumeran todos los problemas:

- **No admite SMTP.** Usa un proveedor HTTP en `QUIRE_EMAIL_PROVIDER_CONFIG`.
- **No hay disco local.** `QUIRE_STORAGE_DRIVER` debe indicar almacenamiento de objetos.
- **No se puede usar tiempo real ni caché en el mismo proceso.** Los Workers no comparten memoria entre solicitudes, por eso se rechazan `QUIRE_REALTIME_DRIVER=inprocess` y `QUIRE_CACHE_DRIVER=memory`.
- **El Worker no puede ejecutar ClamAV, Gotenberg ni ffmpeg.** Se rechazan `CLAMAV_URL`, `GOTENBERG_URL` y `FFMPEG_PATH` si se configuran en el Worker; configúralos en el worker complementario.
- **No admite organizaciones con bases de datos dedicadas.** Los bindings Hyperdrive de un Worker quedan fijos durante el despliegue, así que una organización con su propia base verá una página clara que indica "unavailable here". Dale servicio desde Compose o Vercel.

También debes saber que **la generación previa y la regeneración estática incremental no funcionan en Workers**, sin importar lo que diga la documentación del framework. Cada ruta se genera en cada solicitud.

En este destino, mantén breves las transacciones y nunca las dejes abiertas durante una llamada de red: Hyperdrive restablece el estado de sesión cuando una conexión vuelve al pool, así que el contexto del tenant se establece por transacción.

## Desplegar <!--quire:deploying-->

1. Crea los recursos:
   ```sh
   bun run --bun wrangler hyperdrive create quire-app --connection-string="postgres://quire_app:...@db.example.com:5432/quire"
   bun run --bun wrangler hyperdrive create quire-report --connection-string="postgres://quire_report:...@db.example.com:5432/quire"
   bun run --bun wrangler r2 bucket create quire-files
   bun run --bun wrangler queues create quire-jobs
   ```
   Coloca los dos ID de Hyperdrive en `apps/web/wrangler.jsonc`.
2. Configura los secretos, uno por uno con `bun run --bun wrangler secret put <NAME>` desde `apps/web`: `QUIRE_SECRET_KEY`, `QUIRE_MASTER_KEY`, `QUIRE_EMAIL_PROVIDER_CONFIG`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY`, `QUIRE_COLLAB_SIGNING_KEY` y `QUIRE_REALTIME_WORKER_SECRET`. Las variables normales (`QUIRE_APP_ORIGIN`, `QUIRE_CONTENT_ORIGIN`, `QUIRE_PLATFORM_DOMAINS`, `QUIRE_DATABASE_ID`, `S3_ENDPOINT`, `S3_BUCKET` y `QUIRE_COLLAB_URL`) se agregan a `vars`.
3. Compila y despliega desde `apps/web`:
   ```sh
   NITRO_PRESET=cloudflare-module bun run build
   bun run --bun wrangler deploy
   ```
4. Despliega el Worker en tiempo real con el `QUIRE_REALTIME_WORKER_SECRET` de la capa web y su secreto de token en `QUIRE_REALTIME_TOKEN_SECRET` (la capa web firma los tokens con su propio `QUIRE_REALTIME_TOKEN_SECRET` o, si no está configurado, con `QUIRE_SECRET_KEY`; usa el mismo que usa la capa web). Configura `QUIRE_REALTIME_WORKER_URL` en la capa web con su dirección:
   ```sh
   cd apps/realtime-worker
   bun run --bun wrangler secret put QUIRE_REALTIME_WORKER_SECRET
   bun run --bun wrangler secret put QUIRE_REALTIME_TOKEN_SECRET
   bun run --bun wrangler deploy
   ```
5. Para usar Cloudflare Queues con tareas ligeras, crea una cola por cada una y configura estas variables en el worker complementario (un token de API con permisos de lectura y escritura de Queues):
   ```sh
   bun run --bun wrangler queues create quire-events-notifications
   bun run --bun wrangler queues create quire-events-notifications-dead
   bun run --bun wrangler queues create quire-events-webhooks
   bun run --bun wrangler queues create quire-events-webhooks-dead
   ```
   Configura `QUIRE_QUEUE_DRIVER=cloudflare`, `CLOUDFLARE_ACCOUNT_ID`, `CLOUDFLARE_QUEUES_TOKEN` y `QUIRE_QUEUE_PREFIX` si el prefijo no es `quire-`.
6. Ejecuta el host complementario como se indica en el paso 3 de la [guía de Vercel](/es-419/ops/vercel/). Las migraciones se ejecutan ahí antes de cada despliegue del Worker.

Una configuración rechazada aparece en `bun run --bun wrangler tail` como «The web tier did not start on cloudflare», seguida de cada ajuste que debes cambiar.

Source: https://docs.quirelms.com/es-419/ops/cloudflare/index.mdx