---
title: "La capa web a Vercel"
description: "Executeu la capa web de Quire a Vercel amb un worker complementari."
image: "https://docs.quirelms.com/og.png"
---

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

# La capa web a Vercel

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

El disseny es descriu a `docs/architecture/23-ops.md`, secció 5. Vercel només
executa la capa web. Tota la resta s’executa en un host complementari que
gestioneu vosaltres; és imprescindible.

## Estat d’aquesta versió <!--quire:status-in-this-release-->

La configuració està preparada (`apps/web/vercel.json`, el preset Nitro
`vercel` i les comprovacions d’inici). Vercel necessita emmagatzematge de fitxers
compartit (`QUIRE_STORAGE_DRIVER=s3` o `azure`), un driver de temps real
compatible amb diverses instàncies de funció (`QUIRE_REALTIME_DRIVER=sse` o
`centrifugo`) i un proveïdor de correu electrònic HTTP. Si manca algun
d’aquests elements, la capa web es nega a iniciar-se i el registre n’indica
cadascun.

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

| Component | On s’executa |
| --- | --- |
| `web` | Vercel Functions, entorn Node: pàgines, REST, MCP, LTI i recepció de webhooks |
| `worker`, `scheduler`, `collab`, `content` | Un host complementari: Fly, Railway, ECS o un host Docker propi amb `docker/compose.yaml` |
| Postgres | Extern, darrere d’un gestor de connexions transaccionals: Neon, Supabase o RDS amb PgBouncer |
| Fitxers | S3 o R2. No hi ha disc persistent |
| Tasques en segon pla | S’encauen amb pg-boss dins de la transacció de la petició i les executa el worker complementari. Si s’estableix `QUIRE_QUEUE_DRIVER=vercel` al worker complementari, les tasques lleugeres (notificacions no ordenades i lliuraments de webhooks) passen per Vercel Queues (`VERCEL_QUEUE_REGION`, `VERCEL_QUEUE_TOKEN`) i no es consulta Postgres per aquestes tasques |
| Tasques recurrents | El scheduler complementari. No hi ha cap ruta de Vercel Cron perquè una tasca executada dins d’una funció cron pot superar-ne el temps d’espera |
| Traçat | OpenTelemetry cap al vostre recol·lector, `OTEL_EXPORTER_OTLP_ENDPOINT` |

## Què no pot fer aquest entorn <!--quire:what-this-target-cannot-do-->

La capa web ho comprova en iniciar-se i es nega a continuar si hi ha algun
problema. En lloc d’esperar a fallar quan un correu no s’enviï, enumera tots
els problemes:

- **No hi ha SMTP.** Vercel bloqueja el trànsit SMTP de sortida. Configureu
  `QUIRE_EMAIL_PROVIDER_CONFIG` amb un proveïdor HTTP (Postmark, SES, Mailgun,
  SendGrid o Resend). Es rebutja `QUIRE_SMTP_URL`.
- **No hi ha disc local.** Es rebutja `QUIRE_STORAGE_DRIVER=local`.
- **No hi ha memòria compartida entre invocacions.** Es rebutja
  `QUIRE_REALTIME_DRIVER=inprocess`. Els esdeveniments enviats pel servidor
  queden limitats al temps d’espera de la funció; el client es reconnecta amb
  un cursor, de manera que no es perd cap esdeveniment, però la presència no
  està disponible.
- **Nombre limitat de bases de dades de tenants assignades**: aproximadament
  vuit, perquè cadascuna n’afegeix un altre grup de connexions en un entorn que
  no permet compartir-los.

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

1. Creeu un projecte de Vercel des del repositori amb **Root Directory**
   `apps/web`. `apps/web/vercel.json` estableix les ordres d’instal·lació i
   compilació (`NITRO_PRESET=vercel`) i evita la memòria cau de `/sw.js`.
2. Configureu les variables d’entorn. Com a mínim, des 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` (l’adreça del gestor de connexions),
   `QUIRE_REPORT_DATABASE_URL`, `QUIRE_AUDIT_DATABASE_URL`,
   `QUIRE_DATABASE_ID`, `QUIRE_EMAIL_PROVIDER_CONFIG`, `QUIRE_MAIL_FROM`,
   les opcions d’emmagatzematge i `QUIRE_COLLAB_URL` i
   `QUIRE_COLLAB_SIGNING_KEY` que apuntin al servei collab del host
   complementari. `QUIRE_REPORT_DATABASE_URL` correspon a la base de dades
   física indicada per `DATABASE_URL`. Per a cada base addicional registrada,
   afegiu el seu URL de connexió `quire_report` als entorns web i worker, i
   registreu el nom de la variable com `env:NAME` a la consola de la plataforma.
   Si manca l’URL d’informes d’aquesta base de dades, les consultes d’analytics
   es bloquegen de manera segura.
3. Al host complementari, executeu `docker/compose.yaml` sense el servei `web`,
   amb el mateix `docker/.env`:
   ```sh
   docker compose -f docker/compose.yaml up -d migrate init worker scheduler collab content
   ```
   Les migracions s’hi executen abans d’activar cada desplegament de Vercel.
4. Desplegueu. Si la configuració no és vàlida, el registre de la funció
   comença amb «The web tier did not start on vercel» i enumera els valors que
   cal canviar.

## Actualització <!--quire:upgrading-->

Primer feu la migració des del host complementari, després activeu el nou
desplegament de Vercel i, finalment, renoveu els workers del host complementari:
seguiu l’ordre de [actualització](/ca/ops/upgrade/). Una reversió immediata a Vercel
és una reversió del codi i sempre és segura dins d’una mateixa versió.

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