Déployer Ticketory

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, les adresses vers lesquelles les pages de paiement renvoient les acheteurs, les liens de téléchargement des billets, les adresses des images et l'adresse d'API des frontends en sont toutes construites. REVALIDATE_SECRET remplace la valeur locale par défaut que le site et l'API partagent pour actualiser aussitôt les pages d'événement.

SITE_URL=https://www.your-domain.com
ADMIN_URL=https://dashboard.your-domain.com
API_URL=https://api.your-domain.com
MEDIA_HOSTNAME=api.your-domain.com
REVALIDATE_SECRET=a-long-random-string

MEDIA_HOSTNAME est optionnel, un hôte ou plusieurs séparés par des virgules (ajoutez l'hôte de votre bucket quand les fichiers envoyés vont dans un bucket) : les images de ces hôtes https sont redimensionnées par Next.js, et toute autre image 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, du formulaire de contact et du scan à l'entrée comptent chaque visiteur plutôt que le proxy. Le conteneur de l'API lit back-end/.env s'il existe, c'est aussi là que vont les clés de paiement, d'e-mail, d'IA et de stockage.
• Sans JWT_SECRET à vous, l'API en génère un à son premier démarrage et le garde dans le volume ticketory-data. La base, les fichiers envoyés et les exports CSV se trouvent aussi dans ce volume : sauvegardez-le.
• Le premier démarrage sur un nouveau volume remplit la base avec les organisateurs d'exemple, sauf si SEED_DEMO_DATA=false figure dans le .env. Pour vos propres événements, démarrez sans eux et avec votre propre propriétaire, comme dans Mise en ligne avec votre propre espace de travail plus bas.

L'API à partir de son Dockerfile

Pointez 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, les fichiers envoyés et les exports CSV 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, STOREFRONT_URL avec celle du site, PUBLIC_API_URL avec l'adresse publique de l'API et PUBLIC_MEDIA_URL avec cette adresse suivie de /media.
• Par défaut, l'image a SEED_DEMO_DATA=false : un nouveau volume reçoit seulement les tables, puis le premier démarrage de l'API crée votre espace de travail et son propriétaire à partir de OWNER_EMAIL et OWNER_PASSWORD (voir plus bas). Définissez plutôt SEED_DEMO_DATA=true pour avoir les organisateurs d'exemple. Une base existante n'est jamais remplie une seconde fois.
• 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 (données d'exemple) 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.
• Définissez REVALIDATE_SECRET avec la même longue valeur aléatoire sur l'API et sur le site, et STOREFRONT_INTERNAL_URL quand l'API joint le site à une autre adresse que STOREFRONT_URL.

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 génère les pages d'événement, de lieu et d'organisateur et le sitemap. Avec une adresse d'API publique, cela fonctionne aussi depuis le serveur, et rien de plus n'est nécessaire ; API_INTERNAL_URL à l'exécution la remplace quand le serveur doit utiliser une autre adresse. REVALIDATE_SECRET est aussi une variable d'exécution du site, jamais un argument de build.

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.

Mise en ligne avec votre propre espace de travail

Les organisateurs d'exemple et leurs identifiants servent à essayer Ticketory. Pour vos propres événements, partez d'une nouvelle base sans eux : sur une base sans compte d'équipe ni espace de travail, le premier démarrage de l'API crée les données de base (les 29 permissions, les quatre rôles, les paramètres du site et les trois catégories d'événements), un espace de travail vide et son propriétaire.

1. 01

   Définir les variables du propriétaire

   Dans back-end/.env, ou dans la configuration de votre hébergeur pour l'API. Avec Docker Compose, placez-les dans le .env à côté de docker-compose.yml, avec SEED_DEMO_DATA=false : Compose lit ce fichier en premier puis back-end/.env, dont la valeur l'emporte quand les deux en définissent une.

   back-end/.envCopier

   OWNER_EMAIL=you@your-domain.com
   OWNER_PASSWORD=a-long-password-of-your-own
   OWNER_NAME=Your Name
   WORKSPACE_NAME=Your organisation

   Résultat attendu: OWNER_NAME et WORKSPACE_NAME sont optionnels (Owner et Ticketory s'ils ne sont pas définis), et les deux peuvent être changés plus tard, dans votre profil et sous Paramètres, Général. Le mot de passe doit faire au moins 10 caractères, et avec NODE_ENV=production, la valeur d'exemple de .env.example et le mot de passe des comptes d'exemple sont refusés.
2. 02

   Démarrer sans les données d'exemple, sur une nouvelle base

   Sans Docker, dans le dossier de l'API : yarn build, puis yarn db:sync:prod (pas yarn seed), puis yarn start:prod. Avec Docker Compose, gardez SEED_DEMO_DATA=false dans le .env à côté de docker-compose.yml et lancez docker compose up --build -d sur un nouveau volume (docker compose down -v supprime un volume existant, avec toutes ses données). Un conteneur d'API seul démarre sans -e SEED_DEMO_DATA=true, avec les variables passées par --env-file .env ou -e.

   Résultat attendu: Le journal de l'API affiche Clean start: created the workspace "Your organisation" and its Owner, avec l'e-mail.

   Un problème ?
3. 03

   Connectez-vous et configurez l'espace de travail

   Connectez-vous au tableau de bord avec OWNER_EMAIL et OWNER_PASSWORD. L'espace de travail est vide : ajoutez un lieu, puis votre premier événement. Sa devise est l'USD tant que vous ne la changez pas sous Paramètres, Général, ce que vous pouvez faire jusqu'au paiement du premier billet. Invitez ensuite votre équipe depuis la page Équipe, chacun avec le rôle dont il a besoin.

• Cela n'arrive qu'une fois. Dès qu'un compte d'équipe existe, les variables du propriétaire sont ignorées : un redémarrage ou une seconde copie de l'API ne crée donc rien de plus, et vous pouvez ensuite retirer OWNER_PASSWORD de la configuration. Le mot de passe n'est jamais affiché.
• yarn seed et une base remplie avec les données d'exemple ne les lisent jamais : une telle base a déjà son équipe.
• Le tableau de bord n'a pas de page d'inscription. Chaque autre compte d'équipe s'ajoute avec Invite member sur la page Équipe, avec un rôle et un mot de passe que vous communiquez vous-même (rien n'est envoyé par e-mail).

Partir plutôt des données d'exemple

Une base remplie avec les données d'exemple garde ses quatre organisateurs et leurs comptes. Si vous partez de là, faites-la vôtre avant qu'elle soit accessible depuis Internet :

1. Faites vôtre le propriétaire d'exemple : changez son nom et son e-mail sous Paramètres, Profil, et son mot de passe sous Paramètres, Sécurité. C'est le seul compte qui appartient à tous les espaces de travail d'exemple, et aucun écran n'ajoute un membre existant à un autre espace de travail : gardez-le donc plutôt que de le remplacer par un nouveau compte.
2. Retirez les membres d'exemple dont vous n'avez pas besoin depuis la page Équipe de chaque espace de travail, ou changez leurs mots de passe. Remove retire un membre de l'espace de travail où vous êtes ; le compte est supprimé avec son dernier espace de travail. Vous ne pouvez pas vous retirer vous-même, et chaque espace de travail garde un propriétaire.
3. Définissez le nom de l'espace de travail, l'e-mail de support, la devise, les frais de réservation, le fuseau horaire et les notifications de l'équipe sous Paramètres, Général et Notifications. La devise se verrouille dès que la première commande payée est prise.
4. Archivez ou annulez les événements d'exemple et remplacez les lieux d'exemple par les vôtres, avec leurs plans de salle. Il n'existe ni écran ni route pour créer un autre espace de travail : renommez-en donc un sous Paramètres, Général pour votre propre activité.
5. Les participants créent leur propre compte sur le site, ou achètent en invités. Le participant d'exemple fait partie des données d'exemple : supprimez-le avec le reste.

Mettre à jour une installation qui tourne déjà

Avec NODE_ENV=production, l'API ne modifie jamais les tables elle-même. Après une mise à jour qui ajoute une colonne ou une table, synchronisez le schéma une fois sur la base existante, avant de démarrer la nouvelle version. Celle-ci ajoute la colonne locale sur orders (la langue des e-mails de chaque commande) et la table event_reminders.

Sans Docker, dans le dossier de l'API :

yarn build
yarn db:sync:prod

Cela n'écrit aucune ligne et garde vos données. Avec Docker, le conteneur laisse une base existante tranquille : après docker compose up --build -d, lancez le même script une fois dans le conteneur d'API en marche, puis redémarrez-le (pour un conteneur d'API seul, docker exec -u node <container> node dist/database/sync-schema.js, puis docker restart <container>) :

docker compose exec -u node api node dist/database/sync-schema.js
docker compose restart api

Avec NODE_ENV=development, comme avec yarn dev, l'API met à jour les tables d'elle-même au démarrage.

Mise en ligne

Avant que Ticketory 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 vers le site et le tableau de bord, FRONTEND_URL vers le tableau de bord, STOREFRONT_URL vers le site, PUBLIC_API_URL vers l'API et PUBLIC_MEDIA_URL vers l'API suivie de /media.
3. TICKET_SECRET défini une fois, avant la première vente : il signe les codes QR, et le changer plus tard invalide tous les billets déjà vendus.
4. Vos clés Stripe ou PayPal de production, et les webhooks enregistrés chez chaque fournisseur sur /api/webhooks/stripe et /api/webhooks/paypal à l'adresse de l'API. Quand une clé de production est définie, Test payment disparaît du paiement.
5. La fiscalité configurée pour votre pays : Ticketory n'en applique aucune lui-même.
6. RESEND_API_KEY et MAIL_FROM, sinon les participants ne reçoivent ni e-mails de billets, ni codes d'inscription, ni réinitialisations de mot de passe.
7. La base, les fichiers envoyés et les exports CSV sur un stockage persistant, avec une sauvegarde.
8. La vérification de santé de l'hébergeur sur /api/health, et TRUST_PROXY=1 derrière un proxy.
9. Les deux frontends construits avec les valeurs publiques NEXT_PUBLIC_*, et le même REVALIDATE_SECRET sur l'API et sur le site.
10. Sur le site, votre marque dans src/config/brand.config.ts, et les textes de confidentialité, de conditions et d'annulation dans messages/legal réécrits pour votre activité et votre pays.
11. Votre propre espace de travail depuis un démarrage propre, ou les mots de passe d'exemple changés et les comptes d'exemple inutiles retirés.
12. DEMO_MODE=false sur l'API et NEXT_PUBLIC_DEMO_MODE=false dans les deux frontends, comme livré.

• Variables d'environnement
• Image de marque