Configurer les domaines personnalisés

Configuration et paramètres

Avant toute étape, lisez Avant de commencer et Principes de base du terminal. Ces instructions supposent que vous avez ouvert le monorepo supastack complet dans VS Code ; sa racine package.json marque la racine du référentiel. Dans les commandes pnpm, un package d'espace de travail est une application ou un dossier de code partagé ; dans le produit, un espace de travail est le conteneur de données et la limite de sécurité d'une équipe. corepack pnpm --filter ... sélectionne un package dans le monorepo tandis que les commandes sont exécutées à partir de sa racine. Si vous avez ouvert uniquement un dossier mobile ou de bureau synchronisé, il ne contient pas le backend Web, la configuration Docker ou les scripts racine : exécutez le backend à partir de ce monorepo ou d'un serveur hébergé accessible et utilisez les propres scripts du dossier de plateforme. Une variable d'environnement est un paramètre nommé stocké dans un fichier .env local ou dans votre tableau de bord d'hébergement ; redémarrez l'application concernée après l'avoir modifiée et conservez les secrets du serveur en dehors des valeurs NEXT_PUBLIC_ et EXPO_PUBLIC_.

1. Ouvrez apps/web/.env.local et utilisez CUSTOM_DOMAINS_PROVIDER=local pour prévisualiser l'écran Domaines sans modifications de DNS.

2. Pour un vrai nom d'hôte client, configurez Cloudflare pour SaaS avec votre propre zone, un jeton API limité à cette zone et la cible CNAME ; entrez les valeurs du serveur uniquement sur l'hébergeur Web, pas dans le navigateur.

3. Exécutez Web avec le corepack pnpm --filter @supastack/web dev et ouvrez Paramètres → Domaines en tant que propriétaire/administrateur de l'espace de travail. Attendu : l'adaptateur local active immédiatement un domaine de test ; l'adaptateur Cloudflare attend les enregistrements DNS affichés.

Définissez CUSTOM_DOMAINS_PROVIDER=cloudflare avec CLOUDFLARE_API_TOKEN, CLOUDFLARE_ZONE_ID et CUSTOM_DOMAIN_CNAME_TARGET. Le jeton API nécessite la permission SSL and Certificates:Edit sur la zone (l’API Custom Hostnames se trouve sous /zones/{zone_id}/custom_hostnames). La cible CNAME est un nom d’hôte de votre zone Cloudflare — par exemple customers.example.com — qui résout vers l’application déployée.

Ajoutez dans la zone un enregistrement DNS qui dirige la cible CNAME vers votre origine (l’origine de repli dans les termes de Cloudflare for SaaS). Cloudflare attribue à chaque domaine personnalisé un enregistrement TXT DCV et éventuellement un TXT de propriété ; l’écran des paramètres indique précisément aux clients quels enregistrements créer.

Pour le développement local, utilisez CUSTOM_DOMAINS_PROVIDER=local : chaque nom d’hôte devient immédiatement actif avec la cible customers.localhost. CUSTOM_DOMAINS_PROVIDER=off (valeur par défaut) masque les commandes de cette section.

CUSTOM_DOMAINS_PROVIDER=cloudflare
CLOUDFLARE_API_TOKEN=cf_token_with_ssl_edit
CLOUDFLARE_ZONE_ID=zone_id
CUSTOM_DOMAIN_CNAME_TARGET=customers.example.com

Commandes à copier

Suivez les commentaires pour voir dans quel dossier une commande s'exécute. Si deux terminaux sont étiquetés, ouvrez deux fenêtres de terminal et laissez la première commande s'exécuter pendant que vous utilisez la seconde.

corepack pnpm --filter @supastack/web dev

Processus d’implémentation

Les propriétaires et administrateurs de l’espace de travail gèrent les domaines dans Paramètres → Domaines (cinq par espace). Les clients dirigent un enregistrement CNAME de leur nom d’hôte vers la cible CNAME, ajoutent les enregistrements TXT de propriété et de validation du certificat indiqués, puis choisissent Actualiser l’état. Lorsque Cloudflare confirme l’activation, le nom d’hôte devient une origine approuvée pour l’authentification sur ce déploiement et le nom/logo de l’espace de travail personnalise le chrome de l’application sur ce domaine.

La plupart des fournisseurs DNS n’autorisent pas les enregistrements CNAME sur le domaine racine : les clients doivent utiliser un sous-domaine comme portal.example.com ou un fournisseur qui aplatit les CNAME. Les cookies restent limités à chaque hôte ; un domaine client entraîne donc une session de connexion distincte. L’authentification unique entre domaines personnalisés n’est pas prise en charge.

Vérification et dépannage

Si Cloudflare reste en attente, comparez les enregistrements CNAME et TXT du client avec les valeurs exactes indiquées sur la carte de domaine et laissez à DNS le temps de se mettre à jour. Utilisez un sous-domaine lorsque le fournisseur DNS ne peut pas aplatir un domaine racine CNAME. Si le menu est absent, vérifiez que la fonctionnalité est activée et que l'utilisateur connecté est propriétaire ou administrateur d'un espace de travail.

Un état En attente prolongé signifie généralement que le CNAME du client manque ou que sa propagation n’est pas terminée ; vérifiez les enregistrements DNS affichés sur la fiche du domaine. Un état déplacé ou en échec signifie que Cloudflare ne peut plus résoudre le nom d’hôte vers la zone ; supprimez-le et ajoutez-le de nouveau. Les données de validation sont stockées en JSON fournisseur afin que les futurs formats Cloudflare n’exigent aucune modification de schéma.