--- title: "Despliega tu app del Chatfuel wizard: Vercel, Node.js o Docker" description: "Despliega la app del Chatfuel wizard en Vercel, tu servidor Node.js o Docker, decide quién accede y corrige las dos configuraciones que el servidor rechaza." canonical_url: https://chatfuel.com/es/docs/wizard/deploy markdown_url: https://chatfuel.com/es/docs/wizard/deploy.md last_updated: 2026-10-27 lang: es site: https://chatfuel.com/docs llms_txt: https://chatfuel.com/docs/llms.txt --- # Despliega tu app del Chatfuel wizard: Vercel, Node.js o Docker Despliega la app del Chatfuel wizard en Vercel, tu servidor Node.js o Docker, decide quién accede y corrige las dos configuraciones que el servidor rechaza. La app que escribe el [Chatfuel wizard](https://chatfuel.com/es/docs/wizard/quickstart) funciona en Vercel, en tu propio servidor Node.js o en Docker, con el mismo código. El host decide quién gestiona TLS y cuánto tiempo permanece abierto un WebSocket; no decide quién puede usar la app. Esa segunda pregunta va primero, porque la app se comunica con Chatfuel con tu token de API personal: quien llegue a la app actúa con el acceso de ese token, salvo que el módulo `auth` le pida iniciar sesión. ## Cómo desplegar en Vercel [#cómo-desplegar-en-vercel] El wizard ofrece un despliegue en Vercel al final de su ejecución. Más adelante, ejecútalo desde el directorio de la app: ```bash npm run deploy ``` El script de despliegue (`scripts/deploy-vercel.mjs` en tu app) usa la CLI de Vercel: comprueba que hayas iniciado sesión, vincula el proyecto, envía las variables de tu `.env` al proyecto de Vercel, despliega y le pregunta al nuevo despliegue si quedó configurado. Tu archivo `.env` local nunca se sube; las variables viven en el proyecto de Vercel. * **Solicitudes:** el proxy se ejecuta como una función de Vercel detrás de una reescritura de `/chatfuel/*`. * **Actualizaciones en tiempo real:** un WebSocket dura lo mismo que la duración máxima de la función; después, la app se vuelve a conectar sola. * **Ruta:** la app se sirve desde la raíz del dominio; una subruta como `/app/` necesita un servidor Node.js o Docker. ## Cómo ejecutar la app en tu propio servidor Node.js [#cómo-ejecutar-la-app-en-tu-propio-servidor-nodejs] ```bash npm run build && npm start ``` `npm run build` compila la app del navegador y el servidor. `npm start` ejecuta un solo servidor Node.js que sirve la app compilada y el proxy `/chatfuel/*` en el puerto 3000 (define `PORT` para cambiarlo y `HOST` para elegir la interfaz). Pon delante un proxy inverso con TLS, como nginx o Caddy. ## Cómo ejecutar la app en Docker [#cómo-ejecutar-la-app-en-docker] La app incluye un `Dockerfile` que compila la app e inicia el mismo servidor Node.js en el puerto 3000. Pasa los valores públicos `VITE_*` como argumentos de compilación y todos los secretos en tiempo de ejecución, por ejemplo con `docker run --env-file .env`. Nunca pases `CHATFUEL_TOKEN` ni otro secreto como argumento de compilación: los argumentos de compilación siguen siendo legibles en la imagen. ## Quién puede acceder a la app desplegada [#quién-puede-acceder-a-la-app-desplegada] Sin el módulo `auth`, la app no tiene inicio de sesión: el proxy reenvía cada solicitud que recibe con tu token de API personal. Cualquiera que abra la URL puede leer conversaciones y contactos, enviar mensajes como el bot y cambiar la configuración, aunque el token en sí nunca sale del servidor. Esa configuración sirve para una herramienta de tu propio equipo, fuera del internet público: * en una VPN, una red de Tailscale o WireGuard, o detrás de una lista de IP permitidas de la oficina; * detrás del control de acceso de tu host, como Vercel Deployment Protection, `auth_basic` de nginx o Cloudflare Access; * solo en `localhost`, que es lo que te da `npm run dev`. Una app que clientes o empleados abren desde internet necesita el módulo `auth`: cada persona inicia sesión con tu proyecto de Supabase antes de que el proxy reenvíe nada. Agrégalo con `npx @chatfuel/wizard --embed`. [Módulos del wizard](https://chatfuel.com/es/docs/wizard/modules) describe `auth`. ## Qué configuraciones se niega a ejecutar el servidor [#qué-configuraciones-se-niega-a-ejecutar-el-servidor] El servidor rechaza dos configuraciones en lugar de advertir sobre ellas. `npm start` muestra `REFUSING TO SERVE` y no se inicia, el servidor de desarrollo de Vite con `--host` se detiene antes de montar el proxy, y la función de Vercel responde `503` con el código `ProxyRefusedToServe` a todo excepto a la comprobación de estado. * **Sin inicio de sesión en un host que no es loopback.** El servidor escucha en todas las interfaces de forma predeterminada y, sin `auth`, cualquiera que pueda llegar a él usa tu token. Corrígelo de una de tres formas: instala el módulo `auth`, vincula el servidor a loopback con `HOST=127.0.0.1` o, cuando algo delante de la app ya autentica a cada visitante, define `CHATFUEL_OPEN_PROXY=1` para confirmar que la configuración abierta es intencional. * **`ALLOWED_ORIGINS=*` en un host que no es loopback**, con o sin inicio de sesión. Define `ALLOWED_ORIGINS` con los orígenes que sirven la app, separados por comas, por ejemplo `https://app.example.com`. `CHATFUEL_OPEN_PROXY` no cubre este caso. ## Cómo comprobar un despliegue y proteger el panel de administración [#cómo-comprobar-un-despliegue-y-proteger-el-panel-de-administración] `/chatfuel/healthz` responde en todos los hosts. Devuelve `{"ok":true}` con el estado `200` cuando el servidor está configurado, o `{"ok":false}` con `503` cuando la configuración tiene un problema. Si recibes una página HTML como respuesta, la ruta es incorrecta. El módulo `admin` agrega un panel en `/admin` que puede cambiar toda la cuenta detrás del token. `ADMIN_PASSWORD` es su única protección y debe tener al menos 16 caracteres; si no, el panel se niega a funcionar. Con el módulo `auth` instalado, define también `SUPABASE_SERVICE_ROLE_KEY` para que todas las instancias del servidor compartan un mismo conteo de contraseñas incorrectas; en Vercel, donde puede responder cualquier instancia activa, de lo contrario el conteo se lleva por separado en cada instancia. ## Reglas que debe cumplir todo host [#reglas-que-debe-cumplir-todo-host] * **Las rutas desconocidas responden con `index.html`.** Cada pantalla tiene una dirección real, como `/deals`, y al recargar se debe volver a ella. El servidor Node.js y el `vercel.json` incluido ya lo hacen; en nginx usa `try_files $uri /index.html;`. * **Las variables `VITE_*` se fijan en tiempo de compilación**; todas las demás variables las lee el servidor en tiempo de ejecución. Después de cambiar un valor `VITE_*`, vuelve a compilar. Una app del navegador compilada con la configuración de Supabase y un servidor iniciado sin ella, o al revés, falla al iniciar sesión con `ProxyAuthMisconfigured` o `AuthSessionRequired`. * **Los secretos se quedan en el servidor.** Nada con nombre `VITE_*` puede guardar un secreto, porque esos valores se compilan dentro del código del navegador. ## Problemas comunes [#problemas-comunes] ### REFUSING TO SERVE: open mode on a host that is not loopback [#refusing-to-serve-open-mode-on-a-host-that-is-not-loopback] El servidor se ejecuta sin el módulo `auth` en una dirección a la que otros pueden llegar. Instala `auth`, define `HOST=127.0.0.1` o define `CHATFUEL_OPEN_PROXY=1` cuando tu propio control de acceso ya está delante de la app. ### REFUSING TO SERVE: ALLOWED\_ORIGINS is '\*' [#refusing-to-serve-allowed_origins-is-] Reemplaza `*` por los orígenes exactos de tu app, por ejemplo `ALLOWED_ORIGINS=https://app.example.com`, y reinicia el servidor. ### ADMIN\_PASSWORD must be at least 16 characters. Set a longer one and restart. [#admin_password-must-be-at-least-16-characters-set-a-longer-one-and-restart] El panel de administración rechaza una contraseña corta. Define un `ADMIN_PASSWORD` más largo en el entorno del servidor, o en el proyecto de Vercel, y reinicia o vuelve a desplegar.