---
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-419/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 solo ejecuta la capa web. Todo lo demás se ejecuta en un host complementario que operas tú, y es obligatorio.

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

La configuración está lista (`apps/web/vercel.json`, el preajuste Nitro `vercel` y las comprobaciones de inicio). Vercel requiere almacenamiento de archivos compartido (`QUIRE_STORAGE_DRIVER=s3` o `azure`), un controlador de tiempo real compatible con varias instancias de funciones (`QUIRE_REALTIME_DRIVER=sse` o `centrifugo`) y un proveedor de correo HTTP. Sin estos, la capa web se niega a iniciar y sus registros indican cada configuración faltante.

## 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 |
| Tareas en segundo plano | Se agregan a pg-boss dentro de la transacción de la solicitud y las ejecuta el worker complementario. Con `QUIRE_QUEUE_DRIVER=vercel` en ese worker, las tareas ligeras (entregas de notificaciones y webhooks sin orden definido) pasan por Vercel Queues (`VERCEL_QUEUE_REGION`, `VERCEL_QUEUE_TOKEN`), así no se consulta Postgres mediante el pool para esas tareas |
| Tareas periódicas | El scheduler complementario. No hay una ruta de Vercel Cron porque una tarea que se ejecuta dentro de una función agota su tiempo de espera |
| Trazas | OpenTelemetry a tu colector, `OTEL_EXPORTER_OTLP_ENDPOINT` |

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

La capa web revisa lo siguiente al iniciar y se niega a hacerlo si hay problemas; los enumera en vez de fallar más adelante 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 la función; el cliente vuelve a conectarse con un cursor, así que no se pierde ningún evento, pero la información de presencia no está disponible.
- **Las bases de datos de tenants fijadas tienen un límite** de aproximadamente ocho, porque cada una agrega otro pool de conexiones en un entorno donde no se pueden compartir los pools.

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

1. Crea un proyecto de Vercel desde el repositorio con **Root Directory** 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` (la dirección del pool), `QUIRE_REPORT_DATABASE_URL`, `QUIRE_AUDIT_DATABASE_URL`, `QUIRE_DATABASE_ID`, `QUIRE_EMAIL_PROVIDER_CONFIG`, `QUIRE_MAIL_FROM`, la configuración 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 física indicada por `DATABASE_URL`. Para cada base registrada adicional, agrega su propia URL de conexión `quire_report` a los entornos web y del worker; luego registra su nombre de variable como `env:NAME` en la consola de la plataforma. Las analíticas fallan de forma segura si falta la URL de informes de esa base.
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 en ese host antes de promover cada despliegue de Vercel.
4. Despliega. Si se rechaza la configuración, los registros de la función empiezan con «The web tier did not start on vercel» y enumeran cada ajuste que debes cambiar.

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

Primero ejecuta las migraciones desde el host complementario, luego promueve el nuevo despliegue de Vercel y por último actualiza los workers complementarios, en el orden descrito en [upgrade.md](/es-419/ops/upgrade/). Revertir al instante un despliegue de Vercel revierte el código y siempre es seguro dentro de una misma versión.

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