Déployer l'activité de réservation

Trois façons de déployer

Quelle que soit la méthode choisie, le site et le tableau de bord compilent l'adresse de l'API dans leur JavaScript quand ils sont construits : construisez-les donc avec les adresses publiques, jamais les adresses locales.

Docker Compose sur un seul serveur

Copiez le dossier du pack sur le serveur et placez un .env à côté de docker-compose.yml avec les trois adresses publiques. Les origines autorisées de l'API, l'adresse du tableau de bord, l'adresse du site vers laquelle un processeur de paiement renvoie le voyageur, les adresses des photographies et l'adresse d'API des frontends en sont toutes construites.

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 est optionnel, un hôte ou plusieurs séparés par des virgules (ajoutez l'hôte de votre bucket quand les envois vont vers un bucket) : les photographies de ces hôtes https sont redimensionnées par Next.js, et toute autre photographie se charge telle quelle. Puis construisez et démarrez en arrière-plan :

docker compose up --build -d

• Faites pointer chaque domaine vers le serveur via un reverse proxy qui sert le HTTPS (Caddy, Nginx ou Traefik), en redirigeant vers les ports 3030, 3031 et 8000.
• Derrière ce proxy, définissez TRUST_PROXY=1 dans back-end/.env, pour que les limites de connexion, de réservation, de question et d'avis comptent chaque visiteur plutôt que le proxy. Le conteneur de l'API lit back-end/.env quand il existe, et c'est aussi là que vont les clés de paiement, d'IA, R2 et MCP.
• Sans JWT_SECRET de votre cru, l'API en génère un à son premier démarrage et le conserve dans le volume hollina-data. La base de données et les envois sont aussi dans ce volume, sauvegardez-le donc.
• Le premier démarrage charge le seed de la société de démonstration, sauf si SEED_DEMO_DATA=false figure dans le .env. Gardez-le pour le premier démarrage : c'est le seed qui crée les comptes.

L'API à partir de son Dockerfile

Faites pointer l'hébergeur vers le dossier de l'API (back-end/ dans le Full Stack). L'image écoute sur PORT (8000 sauf si l'hébergeur en impose un autre), répond à GET /api/health dès que sa base répond, et garde SQLite et les fichiers téléversés dans /data.

• Montez un volume persistant sur /data. Sans volume, chaque déploiement repart d'une base vide.
• Définissez CORS_ORIGIN avec les adresses du site et du tableau de bord (séparées par une virgule), FRONTEND_URL avec celle du tableau de bord, SITE_URL avec celle du site, et PUBLIC_MEDIA_URL avec l'adresse publique de l'API suivie de /media.
• Définissez SEED_DEMO_DATA=true pour le premier démarrage sur un nouveau volume : la valeur par défaut de l'image est false, qui crée les tables sans compte. Une base existante n'est jamais réalimentée.
• Définissez votre propre JWT_SECRET, ou laissez le conteneur en générer un et le garder dans /data/.jwt-secret.
• Définissez TRUST_PROXY=1 : une plateforme d'hébergement place un proxy devant le conteneur.
• Sur MySQL (DB_TYPE=mysql et les cinq variables DB_*), le conteneur ne crée pas les tables. Lancez une fois node dist/database/seeder.js (société de démonstration) ou node dist/database/sync-schema.js (tables vides) avec le même environnement.
• Les fichiers téléversés sur le volume survivent à un redéploiement ; pour ne pas les garder sur le serveur, définissez les cinq variables R2_* pour un bucket.

Le site et le tableau de bord à partir de leurs Dockerfiles

Faites pointer l'hébergeur vers le dossier de l'application et donnez-lui les valeurs NEXT_PUBLIC_* comme arguments de build, non comme variables d'exécution : elles sont compilées. Chaque image sert le serveur autonome de Next.js sur PORT (3030 pour le site, 3031 pour le tableau de bord, sauf si l'hébergeur en impose un autre).

Le serveur du site interroge aussi l'API quand il produit les titres de page, le premier rendu de l'accueil et des pages de séjour, et le sitemap. Avec une adresse d'API publique qui fonctionne aussi depuis le serveur, rien de plus n'est nécessaire ; API_INTERNAL_URL à l'exécution la remplace quand le serveur doit utiliser une autre adresse.

Node.js seul

Construisez chaque application une fois sur l'hôte, puis démarrez-la. Réglez le .env des frontends sur les adresses publiques avant yarn build.

L'API écoute sur 0.0.0.0 et lit PORT. Gardez le fichier SQLite et MEDIA_UPLOAD_DIR sur un stockage qui survit à un déploiement, ou utilisez MySQL et un bucket.

Encaisser de vrais paiements

Une installation neuve règle les réservations par carte et PayPal avec le simulateur fourni, qui ne prend aucun argent, jusqu'à ce qu'un processeur soit configuré. Configurez ceux avec lesquels vos voyageurs paieront : avec Stripe seul le site propose la carte, avec PayPal seul PayPal, avec les deux les deux, et le paiement à l'arrivée à côté tant qu'il est activé. Dans l'environnement de l'API :

• Stripe : STRIPE_SECRET_KEY, et un endpoint de webhook à https://<your API>/api/webhooks/payments/stripe pour checkout.session.completed, payment_intent.payment_failed, charge.refunded et charge.dispute.created, dont le secret de signature va dans STRIPE_WEBHOOK_SECRET. Tant qu'il n'est pas défini, chaque webhook Stripe est refusé et une réservation par carte n'est jamais réglée.
• PayPal : PAYPAL_CLIENT_ID, PAYPAL_CLIENT_SECRET, PAYPAL_ENV=live, et un webhook à https://<your API>/api/webhooks/payments/paypal pour PAYMENT.CAPTURE.COMPLETED, PAYMENT.CAPTURE.DENIED, PAYMENT.CAPTURE.REFUNDED et PAYMENT.CAPTURE.REVERSED, dont l'identifiant va dans PAYPAL_WEBHOOK_ID.
• SITE_URL avec l'adresse publique du site : le processeur y renvoie le voyageur vers sa propre page de réservation.
• Le paiement à l'arrivée est un interrupteur dans l'onglet Paiements du tableau de bord, activé par défaut.

• Réservations et paiements

Vos premiers comptes

Il n'y a pas de page d'inscription : les deux comptes du tableau de bord viennent du seed. Démarrez la première fois avec la société de démonstration, connectez-vous, puis faites-la vôtre :

1. Changez les deux mots de passe dans Paramètres, Sécurité, ou créez votre propre Super Admin dans Gestion des admins et supprimez les comptes du seed.
2. Remettez les séjours de démonstration en brouillon pour que le site ne les propose plus. Le tableau de bord ne permet pas de supprimer un séjour, et l'API n'en supprime un que tant qu'aucune de ses réservations ne retient de nuits, ce qui est toujours le cas d'une réservation terminée.
3. Définissez le nom de la société, son slogan, sa description, son e-mail de contact, son téléphone et sa ligne d'adresse sous Paramètres, Société ; le séjour à la une et les séjours en vedette sous Paramètres, Page d'accueil ; le paiement à l'arrivée et la politique d'annulation sous Paramètres, Paiements.
4. Renommez ou remplacez les destinations de démonstration sous Paramètres, Destinations. Une destination qui a encore des séjours ne peut pas être supprimée.

Mise en ligne

Avant que l'activité de réservation soit accessible depuis internet :

1. Dans l'environnement de l'API, NODE_ENV=production et un JWT_SECRET long et aléatoire à vous (Docker en génère un quand aucun n'est défini). En production, l'API refuse de démarrer sans CORS_ORIGIN et indique quelle valeur manque.
2. CORS_ORIGIN sur le site et le tableau de bord, FRONTEND_URL sur le tableau de bord, SITE_URL sur le site, PUBLIC_MEDIA_URL sur l'API suivie de /media.
3. Stripe, PayPal ou les deux configurés avec leurs webhooks. Tant que ce n'est pas fait, le simulateur confirme chaque réservation par carte et PayPal sans prendre d'argent, et le journal de démarrage de l'API affiche Payment simulator active.
4. La base et les fichiers téléversés sur un stockage persistant, avec une sauvegarde.
5. La vérification de santé de l'hébergeur sur /api/health, et TRUST_PROXY=1 derrière un proxy.
6. Les deux frontends construits avec les valeurs publiques NEXT_PUBLIC_*.
7. Sur le site, votre marque dans src/config/brand.config.ts, et la politique de confidentialité dans messages/privacy réécrite pour votre société et votre pays.
8. Les mots de passe du seed changés, ou les comptes du seed supprimés.
9. DEMO_MODE=false sur l'API et NEXT_PUBLIC_DEMO_MODE=false dans les deux frontends, comme livré.

• Variables d'environnement
• Image de marque