---
title: "La capa web en Vercel"
description: "Ejecuta la capa web de Quire en Vercel con un worker complementario."
image: "https://docs.quirelms.com/og.png"
---

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

# La capa web en Vercel

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

El diseño se describe en la sección 5 de `docs/architecture/23-ops.md`. Vercel ejecuta solo la capa web. Todo lo demás se ejecuta en un host complementario que operas tú y que es obligatorio.

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

La configuración está preparada (`apps/web/vercel.json`, el preajuste Nitro `vercel` y las comprobaciones de inicio). Vercel necesita almacenamiento de archivos compartido (`QUIRE_STORAGE_DRIVER=s3` o `azure`), un controlador en tiempo real compatible con varias instancias de funciones (`QUIRE_REALTIME_DRIVER=sse` o `centrifugo`) y un proveedor de correo electrónico HTTP. Sin ellos, la capa web se niega a iniciarse y su registro indica cada parámetro que falta.

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

| Componente | Dónde se ejecuta |
| --- | --- |
| `web` | Vercel Functions, entorno Node: páginas, REST, MCP, LTI y recepción de webhooks |
| `worker`, `scheduler`, `collab`, `content` | Un host complementario: Fly, Railway, ECS o tu propio host Docker con `docker/compose.yaml` |
| Postgres | Externa, detrás de un pool de transacciones: Neon, Supabase o RDS con PgBouncer |
| Archivos | S3 o R2. No hay disco persistente |
| Trabajos en segundo plano | Se añaden a pg-boss dentro de la transacción de la solicitud y los ejecuta el worker complementario. Con `QUIRE_QUEUE_DRIVER=vercel` en el worker complementario, los trabajos ligeros (entregas desordenadas de notificaciones y webhooks) pasan por Vercel Queues (`VERCEL_QUEUE_REGION`, `VERCEL_QUEUE_TOKEN`), evitando consultar Postgres mediante el pool para esos trabajos |
| Trabajos periódicos | El scheduler complementario. No hay una ruta Vercel Cron, porque un trabajo que se ejecuta dentro de una función cron agota su tiempo de espera |
| Trazas | OpenTelemetry al colector que hayas configurado, `OTEL_EXPORTER_OTLP_ENDPOINT` |

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

La capa web comprueba estos requisitos al iniciarse y se niega a arrancar, indicando todos los problemas, en lugar de fallar más tarde cuando no se envíe el primer correo:

- **No admite SMTP.** Vercel bloquea SMTP saliente. Configura `QUIRE_EMAIL_PROVIDER_CONFIG` con un proveedor HTTP (Postmark, SES, Mailgun, SendGrid o Resend). Se rechaza `QUIRE_SMTP_URL`.
- **No hay disco local.** Se rechaza `QUIRE_STORAGE_DRIVER=local`.
- **Las invocaciones no comparten memoria.** Se rechaza `QUIRE_REALTIME_DRIVER=inprocess`. Los eventos enviados por el servidor se limitan al tiempo de ejecución de la función; el cliente vuelve a conectarse con un cursor, por lo que no se pierde ningún evento, aunque no hay información de presencia.
- **Hay un límite de aproximadamente ocho bases de datos de tenants fijadas**, porque cada una requiere otro pool de conexiones en un entorno donde no se pueden compartir los pools.

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

1. Crea un proyecto de Vercel desde el repositorio con **Root Directory** establecido en `apps/web`. `apps/web/vercel.json` configura los comandos de instalación y compilación (`NITRO_PRESET=vercel`) y sirve `/sw.js` sin caché.
2. Configura las variables de entorno. Como mínimo, toma de `docker/.env.example`: `QUIRE_DEPLOY_TARGET=vercel`, `QUIRE_APP_ORIGIN`, `QUIRE_CONTENT_ORIGIN`, `QUIRE_PLATFORM_DOMAINS`, `QUIRE_SECRET_KEY`, `QUIRE_MASTER_KEY`, `DATABASE_URL` (dirección del pool), `QUIRE_REPORT_DATABASE_URL`, `QUIRE_AUDIT_DATABASE_URL`, `QUIRE_DATABASE_ID`, `QUIRE_EMAIL_PROVIDER_CONFIG`, `QUIRE_MAIL_FROM`, los parámetros de almacenamiento, y `QUIRE_COLLAB_URL` y `QUIRE_COLLAB_SIGNING_KEY` con los datos del servicio collab complementario.
   `QUIRE_REPORT_DATABASE_URL` corresponde a la base de datos física indicada en `DATABASE_URL`. Para cada base de datos registrada adicional, añade su propia URL de conexión `quire_report` a los entornos web y del worker; luego registra en la consola de la plataforma su nombre de variable de entorno como `env:NAME`. Las analíticas fallan de forma segura si falta la URL de informes de esa base de datos.
3. En el host complementario, ejecuta `docker/compose.yaml` sin el servicio `web` y con el mismo `docker/.env`:
   ```sh
   docker compose -f docker/compose.yaml up -d migrate init worker scheduler collab content
   ```
   Las migraciones se ejecutan allí antes de promover cada despliegue de Vercel.
4. Despliega. Si se rechaza la configuración, el registro de la función comienza con «The web tier did not start on vercel» y enumera cada parámetro que debes cambiar.

## Actualizaciones <!--quire:upgrading-->

Primero ejecuta las migraciones desde el host complementario, luego promueve el nuevo despliegue de Vercel y, por último, actualiza gradualmente los workers complementarios, siguiendo el orden de [upgrade.md](/es/ops/upgrade/). Una reversión instantánea de Vercel revierte el código y siempre es segura dentro de una versión.

Source: https://docs.quirelms.com/es/ops/vercel/index.mdx