Despliega el negocio de reservas

Tres formas de desplegar

Elijas la forma que elijas, el sitio web y el panel compilan la dirección de la API en su JavaScript cuando se construyen, así que constrúyelos con las direcciones públicas, nunca con las locales.

Docker Compose en un servidor

Copia la carpeta del paquete al servidor y pon un .env junto a docker-compose.yml con las tres direcciones públicas. Los orígenes permitidos de la API, la dirección del panel, la dirección del sitio web a la que un procesador de pagos devuelve al huésped, las direcciones de las fotografías y la dirección de la API de los frontends se construyen todas a partir de ellas.

SITE_URL=https://www.your-company.com
ADMIN_URL=https://admin.your-company.com
API_URL=https://api.your-company.com
MEDIA_HOSTNAME=api.your-company.com

MEDIA_HOSTNAME es opcional, un host o varios separados por comas (añade el host de tu bucket cuando las subidas vayan a uno): Next.js redimensiona las fotografías de esos hosts https, y cualquier otra fotografía se carga tal cual. Luego construye e inicia en segundo plano:

docker compose up --build -d

• Apunta cada dominio al servidor mediante un proxy inverso que sirva HTTPS (Caddy, Nginx o Traefik), reenviando a los puertos 3030, 3031 y 8000.
• Detrás de ese proxy, define TRUST_PROXY=1 en back-end/.env, para que los límites de inicio de sesión, reserva, pregunta y reseña cuenten a cada visitante en lugar de al proxy. El contenedor de la API lee back-end/.env cuando existe, y ahí también van las claves de pagos, IA, R2 y MCP.
• Sin un JWT_SECRET propio, la API genera uno en su primer inicio y lo guarda en el volumen hollina-data. La base de datos y las subidas también viven en ese volumen, así que haz una copia de seguridad.
• El primer inicio carga la empresa de demostración a menos que SEED_DEMO_DATA=false esté en el .env. Mantenlo en el primer inicio: la carga inicial es lo que crea las cuentas.

La API desde su Dockerfile

Apunta el host a la carpeta de la API (back-end/ en el Full Stack). La imagen escucha en PORT (8000 salvo que el host defina otro), responde a GET /api/health cuando su base de datos responde, y guarda SQLite y las subidas en /data.

• Monta un volumen persistente en /data. Sin uno, cada despliegue empieza con una base de datos vacía.
• Define CORS_ORIGIN con las direcciones del sitio web y del panel (separadas por comas), FRONTEND_URL con la del panel, SITE_URL con la del sitio web, y PUBLIC_MEDIA_URL con la dirección pública de la API seguida de /media.
• Define SEED_DEMO_DATA=true para el primer inicio en un volumen nuevo: el valor por defecto de la imagen es false, que crea las tablas sin cuentas. Una base de datos existente nunca se vuelve a cargar.
• Define tu propio JWT_SECRET, o deja que el contenedor genere uno y lo guarde en /data/.jwt-secret.
• Define TRUST_PROXY=1: una plataforma de alojamiento pone un proxy delante del contenedor.
• En MySQL (DB_TYPE=mysql y las cinco variables DB_*), el contenedor no crea las tablas. Ejecuta node dist/database/seeder.js (empresa de demostración) o node dist/database/sync-schema.js (tablas vacías) una vez con el mismo entorno.
• Las subidas en el volumen sobreviven a un nuevo despliegue; para mantenerlas fuera del servidor, define las cinco variables R2_* para un bucket.

El sitio web y el panel desde sus Dockerfiles

Apunta el host a la carpeta de la aplicación y dale los valores NEXT_PUBLIC_* como argumentos de construcción, no como variables de ejecución: se compilan dentro. Cada imagen sirve el servidor independiente de Next.js en PORT (3030 para el sitio web, 3031 para el panel, salvo que el host defina otro).

El servidor del sitio web también consulta la API mientras renderiza los títulos de página, el primer renderizado de las páginas de inicio y de alojamiento, y el mapa del sitio. Con una dirección pública de la API que funcione también desde el servidor, no hace falta nada más; API_INTERNAL_URL en tiempo de ejecución la sustituye cuando el servidor debe usar otra dirección.

Node.js sin más

Construye cada aplicación una vez en el host y luego inicia. Define el .env de los frontends con las direcciones públicas antes de yarn build.

La API se enlaza a 0.0.0.0 y lee PORT. Mantén el archivo SQLite y MEDIA_UPLOAD_DIR en un almacenamiento que sobreviva a un despliegue, o usa MySQL y un bucket.

Recibe pagos reales

Una instalación nueva liquida las reservas con tarjeta y PayPal con el simulador incluido, que no cobra nada, hasta que se configura un procesador. Configura aquellos con los que pagarán tus huéspedes: con Stripe solo, el sitio web ofrece tarjeta; con PayPal solo, PayPal; con ambos, los dos, y el pago a la llegada junto a ellos mientras esté activado. En el entorno de la API:

• Stripe: STRIPE_SECRET_KEY, y un endpoint de webhook en https://<your API>/api/webhooks/payments/stripe para checkout.session.completed, payment_intent.payment_failed, charge.refunded y charge.dispute.created, cuyo secreto de firma va en STRIPE_WEBHOOK_SECRET. Mientras no esté definido, se rechaza todo webhook de Stripe y una reserva con tarjeta nunca se liquida.
• PayPal: PAYPAL_CLIENT_ID, PAYPAL_CLIENT_SECRET, PAYPAL_ENV=live, y un webhook en https://<your API>/api/webhooks/payments/paypal para PAYMENT.CAPTURE.COMPLETED, PAYMENT.CAPTURE.DENIED, PAYMENT.CAPTURE.REFUNDED y PAYMENT.CAPTURE.REVERSED, cuyo id va en PAYPAL_WEBHOOK_ID.
• SITE_URL con la dirección pública del sitio web: el procesador devuelve allí al huésped a su propia página de reserva.
• El pago a la llegada es un interruptor en la pestaña Pagos del panel, activado por defecto.

• Reservas y pagos

Tus primeras cuentas

No hay página de registro: las dos cuentas del panel vienen de la carga inicial. Empieza la primera vez con la empresa de demostración, inicia sesión y luego hazla tuya:

1. Cambia ambas contraseñas en Ajustes, Seguridad, o crea tu propio Super Admin en Gestión de administradores y elimina las cuentas de la carga inicial.
2. Devuelve los alojamientos de demostración a borrador para que el sitio web deje de ofrecerlos. El panel no tiene opción para eliminar un alojamiento, y la API solo elimina uno mientras ninguna de sus reservas ocupe noches, cosa que una reserva completada siempre hace.
3. Define el nombre, el eslogan, la descripción, el correo electrónico, el teléfono y la dirección de la empresa en Ajustes, Empresa; el alojamiento principal y los alojamientos destacados en Ajustes, Página de inicio; el pago a la llegada y la política de cancelación en Ajustes, Pagos.
4. Renombra o reemplaza los destinos de demostración en Ajustes, Destinos. Un destino que aún tiene alojamientos no se puede eliminar.

Pasar a producción

Antes de que el negocio de reservas sea accesible desde internet:

1. En el entorno de la API, NODE_ENV=production y un JWT_SECRET largo y aleatorio propio (Docker genera uno cuando no hay ninguno). En producción la API se niega a iniciar sin CORS_ORIGIN y dice qué valor falta.
2. CORS_ORIGIN con el sitio web y el panel, FRONTEND_URL con el panel, SITE_URL con el sitio web, PUBLIC_MEDIA_URL con la API seguida de /media.
3. Stripe, PayPal o ambos configurados con sus webhooks. Mientras no lo estén, el simulador confirma todas las reservas con tarjeta y PayPal sin cobrar nada, y el registro de inicio de la API dice Payment simulator active.
4. La base de datos y las subidas en almacenamiento persistente, con una copia de seguridad.
5. La comprobación de estado del host en /api/health, y TRUST_PROXY=1 detrás de un proxy.
6. Ambos frontends construidos con los valores públicos de NEXT_PUBLIC_*.
7. En el sitio web, tu marca en src/config/brand.config.ts y la política de privacidad en messages/privacy reescrita para tu empresa y tu país.
8. Las contraseñas de la carga inicial cambiadas, o las cuentas de la carga inicial eliminadas.
9. DEMO_MODE=false en la API y NEXT_PUBLIC_DEMO_MODE=false en ambos frontends, tal como se entrega.

• Variables de entorno
• Marca