Déployer l'agence
Mettez en ligne le site, le tableau de bord et l'API : Docker Compose sur un seul serveur, une application par hébergeur à partir de son Dockerfile, ou Node.js seul.
Pour le pack Full Stack
Trois façons de déployer
| Méthode | Idéal pour | Ce qu'il vous faut |
|---|---|---|
| Docker Compose sur un seul serveur | Un VPS que vous contrôlez, les trois applications ensemble | Le pack Full Stack, Docker sur le serveur, un reverse proxy pour le HTTPS |
| Une application par hébergeur, à partir de son Dockerfile | Railway, Render, Fly.io et les autres hébergeurs qui construisent depuis un Dockerfile | Le dossier de chaque application ; un volume ou MySQL et un bucket pour l'API |
| Node.js seul | N'importe quel hébergeur Node | Node.js 22 ou plus récent et Yarn 4 sur l'hôte |
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, les adresses des photos et l'adresse de l'API côté frontends en sont tous déduits.
SITE_URL=https://www.your-agency.com
ADMIN_URL=https://admin.your-agency.com
API_URL=https://api.your-agency.com
MEDIA_HOSTNAME=api.your-agency.comMEDIA_HOSTNAME est optionnel, un hôte ou plusieurs séparés par des virgules (ajoutez l'hôte de votre bucket quand les fichiers sont téléversés vers un bucket) : les photos de ces hôtes https sont redimensionnées par Next.js, et toute autre photo 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,3031et8000. - Derrière ce proxy, définissez
TRUST_PROXY=1dansback-end/.env, pour que les limites de connexion, de formulaire de contact et de demande de visite comptent chaque visiteur plutôt que le proxy. Le conteneur de l'API litback-end/.envs'il existe, c'est aussi là que vont les clés optionnelles. - Sans
JWT_SECRETà vous, l'API en génère un à son premier démarrage et le garde dans le volumevelra-data. La base et les fichiers téléversés vivent aussi dans ce volume : sauvegardez-le. - Le premier démarrage alimente l'agence de démonstration, sauf si
SEED_DEMO_DATA=falseest 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_ORIGINavec les adresses du site et du tableau de bord (séparées par des virgules),FRONTEND_URLavec celle du tableau de bord, etPUBLIC_MEDIA_URLavec l'adresse publique de l'API suivie de/media. - Définissez
SEED_DEMO_DATA=truepour le premier démarrage sur un nouveau volume : la valeur par défaut de l'image estfalse, 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. - Avec MySQL (
DB_TYPE=mysqlet les cinq variablesDB_*), le conteneur ne crée pas les tables. Lancez une foisnode dist/database/seeder.js(agence de démonstration) ounode 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).
| Argument de build | Application | Valeur |
|---|---|---|
NEXT_PUBLIC_API_BASE_URL | Les deux | L'adresse publique de l'API suivie de /api |
NEXT_PUBLIC_SITE_URL | Les deux | L'adresse publique du site : URL canoniques et sitemap sur le site, lien « View website » dans le tableau de bord |
NEXT_PUBLIC_MEDIA_HOSTNAME | Les deux | Optionnel. Les hôtes https qui servent les photos (le domaine de l'API, celui de votre bucket, ou les deux), séparés par des virgules |
NEXT_PUBLIC_WEBSOCKET_BASE_URL | Tableau de bord | L'adresse publique de l'API sans /api, pour les notifications en direct |
Le serveur du site interroge aussi l'API pendant le rendu des pages de bien et du sitemap. Avec une adresse publique d'API 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.
| Application | Build | Démarrage |
|---|---|---|
| API | yarn build, puis une fois yarn seed:prod (agence de démonstration) ou yarn db:sync:prod (tables vides) | yarn start:prod |
| Site public | yarn build | yarn start (port 3030) |
| Tableau de bord de l'agence | yarn build | yarn start (port 3031) |
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.
Vos premiers comptes
Il n'y a pas de page d'inscription : les deux comptes du tableau de bord viennent du seed. Pour le premier démarrage, utilisez l'agence de démonstration, connectez-vous, puis faites-la vôtre :
- 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.
- Archivez ou supprimez les biens d'exemple, et supprimez les quartiers d'exemple dont vous n'avez pas besoin.
- Clôturez les demandes d'exemple et annulez les visites d'exemple : elles n'ont pas de suppression.
- Renseignez le nom, le slogan, la description et l'e-mail de contact de l'agence dans Paramètres, Agence, et les biens à la une de la page d'accueil dans Paramètres, Page d'accueil.
Mise en ligne
Avant que l'agence soit accessible depuis Internet :
- Dans l'environnement de l'API,
NODE_ENV=productionet unJWT_SECRETlong et aléatoire à vous (Docker en génère un quand aucun n'est défini). En production, l'API refuse de démarrer sansCORS_ORIGINet indique quelle valeur manque. CORS_ORIGINsur le site et le tableau de bord,FRONTEND_URLsur le tableau de bord,PUBLIC_MEDIA_URLsur l'API suivie de/media.- La base et les fichiers téléversés sur un stockage persistant, avec une sauvegarde.
- La vérification de santé de l'hébergeur sur
/api/health, etTRUST_PROXY=1derrière un proxy. - Les deux frontends construits avec les valeurs publiques
NEXT_PUBLIC_*. - Sur le site, votre marque dans
src/config/brand.config.ts, et la politique de confidentialité dansmessages/privacyréécrite pour votre agence et votre pays. - Les mots de passe du seed changés, ou les comptes du seed supprimés.
DEMO_MODE=falsesur l'API etNEXT_PUBLIC_DEMO_MODE=falsedans les deux frontends, comme livré.
Pas pour une agence avec de vraies données
yarn setup:fresh construit, supprime chaque table et alimente la base, à chaque exécution, et yarn db:reset supprime chaque table. Ils conviennent à un environnement tout neuf, jamais à une commande de démarrage ou de build.