Votre client tape app.theircustomer.com dans son navigateur et attend. Derrière ce délai de trois secondes, votre infrastructure orchestre une recherche DNS, valide un certificat générique, route à travers votre proxy inverse, et affiche son tableau de bord personnalisé — tout sans qu'il connaisse votre adresse IP réelle. J'ai implémenté ce modèle de domaine personnalisé quatre fois sur différentes piles technologiques, et chaque implémentation a révélé des pièges qui n'apparaissaient jamais dans la spécification du produit : les limites de débit de Let's Encrypt qui bloquent votre dixième intégration client, le comportement d'aplatissement des CNAME qui casse sur certains fournisseurs DNS, les délais de propagation qui créent des montagnes de tickets support lors de la semaine de lancement. Vous allez architecting cela une fois en pensant que c'est un projet de deux sprints — avant de découvrir les cas limites qui transforment l'automatisation SSL en un week-end de débogage API Cloudflare et de validation de chaînes de certificats.

Cet article est le manuel que j'aurais aimé avoir. Nous allons couvrir les sous-domaines génériques pour les applications multi-locataires, l'approvisionnement automatisé en SSL avec Let's Encrypt et les alternatives, les domaines de marque personnalisés où les clients apportent les leurs, et les préoccupations opérationnelles qui vous piqueront à 2h du matin si vous ne les planifiez pas.

Table des matières

Domaines personnalisés pour SaaS : Sous-domaines génériques et SSL automatisé

Pourquoi les domaines personnalisés sont importants pour les SaaS

Les domaines personnalisés ne sont pas qu'une simple fonction de vanité. Ils sont un signal de confiance. Quand le client de votre client visite portal.acmecorp.com au lieu de acmecorp.your-saas.io, cela renforce la marque du client. Cela supprime les frictions. Et pour beaucoup de contrats entreprise, c'est une exigence stricte — l'équipe d'approvisionnement n'approuvera pas un logiciel qui force les employés sur un domaine tiers.

Il y a aussi un angle SEO. Si vous construisez un SaaS impliquant des pages accessibles au public (pensez aux boutiques Shopify, générateurs de pages d'atterrissage, bases de connaissances ou portails clients), les clients ont besoin de leurs propres domaines pour construire l'autorité du domaine. Vous ne pouvez pas faire cela sur un sous-domaine de quelqu'un d'autre. Enfin, vous pouvez, mais c'est suboptimal.

Les trois modèles les plus courants que j'observe :

  1. Sous-domaines de plateforme — customer.your-app.com (le plus facile)
  2. Sous-domaines personnalisés — app.customer.com (complexité moyenne)
  3. Domaines apex personnalisés — customer.com (le plus difficile, car les enregistrements CNAME ne fonctionnent pas à l'apex)

La plupart des produits SaaS matures finissent par supporter tous les trois.

Vue d'ensemble architecturale : trois approches

Avant de rentrer dans les détails d'implémentation, regardons les trois principales approches architecturales et quand chacune a du sens.

Approche Complexité Idéal pour Méthode SSL Exigence DNS
Sous-domaine générique Faible Sous-domaines contrôlés par la plateforme Certificat générique unique Enregistrement DNS A/AAAA générique
Proxy inverse avec SNI Moyen Domaines personnalisés à l'échelle modérée Certificat par domaine via ACME CNAME client ou enregistrement A
CDN/Edge avec domaines personnalisés Faible-Moyen Grande échelle, distribution mondiale Géré par le fournisseur CDN CNAME client ou enregistrement A
Équilibreur de charge dédié par locataire Élevée Exigences d'isolement entreprise Certificat par locataire Délégation DNS client

Pour la plupart des applications SaaS, vous commencerez avec des sous-domaines génériques et ajouterez progressivement le support des domaines personnalisés basé sur proxy inverse. Approfondissons chacun.

Sous-domaines génériques pour la multi-location

C'est votre point de départ. Chaque locataire obtient {slug}.yourapp.com. Voici comment le configurer correctement.

Configuration DNS

Vous avez besoin d'un enregistrement DNS générique :

*.yourapp.com.  300  IN  A      203.0.113.10
*.yourapp.com.  300  IN  AAAA   2001:db8::1

Cela signifie que n'importe quel sous-domaine de yourapp.com se résout à votre serveur. Votre application lit ensuite l'en-tête Host pour déterminer quel locataire servir.

Routage au niveau de l'application

Dans une application Next.js (que nous construisons beaucoup chez Social Animal), vous géreriez cela dans le middleware :

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

export function middleware(request: NextRequest) {
  const hostname = request.headers.get('host') || '';
  const subdomain = hostname.split('.')[0];
  
  // Ignorer le domaine principal et les sous-domaines connus
  if (['www', 'app', 'api'].includes(subdomain)) {
    return NextResponse.next();
  }
  
  // Réécrire vers le chemin spécifique au locataire
  const url = request.nextUrl.clone();
  url.pathname = `/tenant/${subdomain}${url.pathname}`;
  return NextResponse.rewrite(url);
}

export const config = {
  matcher: ['/((?!_next|api|static).*)'],
};

Pour les sites basés sur Astro (un autre framework que nous utilisons largement), vous géreriez cela dans votre middleware serveur ou à la limite.

Certificat SSL générique

Un seul certificat générique couvre tous les sous-domaines :

certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d 'yourapp.com' \
  -d '*.yourapp.com'

Note : les certificats génériques de Let's Encrypt exigent une validation de défi DNS-01. Vous ne pouvez pas utiliser HTTP-01 pour les génériques. Cela signifie que vous avez besoin d'un accès API à votre fournisseur DNS. Certbot a des plugins pour Cloudflare, Route53, Google Cloud DNS, et la plupart des fournisseurs majeurs.

Les certificats génériques de Let's Encrypt sont valides pendant 90 jours, donc automatisez ce renouvellement. Sérieusement. Définissez une alerte de surveillance si le renouvellement échoue — ne soyez pas la personne qui met hors ligne 500 sites clients parce qu'un certificat a expiré.

Domaines personnalisés pour SaaS : Sous-domaines génériques et SSL automatisé - architecture

SSL automatisé avec Let's Encrypt

Quand les clients apportent leurs propres domaines, vous avez besoin de certificats par domaine. C'est là que les choses deviennent intéressantes.

Le protocole ACME

Let's Encrypt utilise le protocole ACME (Automatic Certificate Management Environment). Les deux défis qui vous intéresseront :

  • HTTP-01 : Vous prouvez la propriété du domaine en servant un fichier spécifique à http://yourdomain.com/.well-known/acme-challenge/{token}. Le plus facile à automatiser, fonctionne pour les domaines individuels.
  • DNS-01 : Vous prouvez la propriété en créant un enregistrement TXT spécifique. Exigé pour les génériques, plus difficile à automatiser pour les domaines clients (vous ne contrôlez pas leur DNS).

Pour les domaines personnalisés, vous allez presque toujours utiliser HTTP-01. Le flux ressemble à ceci :

  1. Le client ajoute un CNAME pointant son domaine vers votre plateforme
  2. Votre système détecte que le DNS se résout correctement
  3. Vous initiez une demande de certificat ACME
  4. Let's Encrypt envoie un défi HTTP-01
  5. Votre serveur répond avec le jeton de défi correct
  6. Le certificat est émis et stocké
  7. Votre proxy inverse commence à servir HTTPS pour ce domaine

Caddy : l'option paresseuse (intelligente)

Honnêtement, si vous n'êtes pas déjà engagé envers nginx, utilisez simplement Caddy. Il gère HTTPS automatique prêt à l'emploi, y compris TLS à la demande pour les domaines inconnus :

{
  on_demand_tls {
    ask http://localhost:5555/check-domain
    interval 2m
    burst 5
  }
}

https:// {
  tls {
    on_demand
  }
  reverse_proxy localhost:3000
}

L'endpoint ask est critique — c'est où Caddy demande à votre application si un domaine est réellement un domaine client valide avant de demander un certificat. Sans cela, n'importe qui pourrait pointer son domaine vers votre IP et déclencher des demandes de certificats, potentiellement consumant vos limites de débit Let's Encrypt.

// Endpoint /check-domain
app.get('/check-domain', async (req, res) => {
  const domain = req.query.domain;
  const isValid = await db.customDomains.findOne({ 
    domain, 
    verified: true,
    active: true 
  });
  
  if (isValid) {
    res.status(200).send('OK');
  } else {
    res.status(404).send('Not found');
  }
});

Approche Nginx + Certbot

Si vous exécutez déjà nginx, vous pouvez utiliser certbot avec le plugin webroot :

certbot certonly --webroot -w /var/www/certbot \
  -d customer-domain.com \
  --non-interactive --agree-tos \
  --email ssl@yourapp.com

Vous devrez mettre à jour dynamiquement les configs nginx et recharger :

server {
    listen 443 ssl;
    server_name customer-domain.com;
    
    ssl_certificate /etc/letsencrypt/live/customer-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/customer-domain.com/privkey.pem;
    
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Cela fonctionne mais c'est pénible à gérer à l'échelle. Chaque nouveau domaine signifie générer une configuration, demander un certificat, et recharger nginx. Vous voudrez construire de l'automatisation autour de cela, et honnêtement le TLS à la demande de Caddy est juste plus facile.

Limites de Let's Encrypt (2025)

Celles-ci comptent et vous devez les planifier :

Limite Valeur Notes
Certificats par domaine enregistré 50/semaine Par votre domaine racine
Certificat dupliqué 5/semaine Le même ensemble exact de noms d'hôtes
Validations échouées 5/heure par compte par nom d'hôte Peut vous bloquer rapidement
Nouvelles commandes 300/3 heures À l'échelle du compte
Autorisations en attente 300/compte Nettoyez les anciennes

Avec 50 certs par semaine, si vous intégrez plus de ~7 domaines personnalisés par jour, vous devez penser à cela. Options :

  • Utiliser une autre AC ACME (ZeroSSL, BuyPass) comme secours
  • Demander une augmentation de la limite de débit Let's Encrypt (ils les accordent pour les cas d'usage SaaS légitime)
  • Pré-valider le DNS avant de tenter l'issuance du certificat
  • Implémenter une logique de nouvelle tentative avec backoff exponentiel

Domaines de marque personnalisés : le flux complet

Voici le voyage utilisateur complet que je recommande, ayant construit ce flux plusieurs fois.

Étape 1 : Le client entre le domaine dans votre tableau de bord

Fournissez des instructions claires. Montrez-leur exactement quel enregistrement DNS créer :

Type : CNAME
Nom d'hôte : portal (ou n'importe quel sous-domaine qu'ils veulent)
Valeur : custom.yourapp.com
TTL : 300

Pour les domaines apex (bare customer.com), ils ont besoin d'un enregistrement A pointant vers votre IP, ou ils ont besoin d'un fournisseur DNS qui supporte l'aplatissement CNAME (Cloudflare, enregistrements ALIAS de Route53, etc.).

Étape 2 : Vérification DNS

Ne vérifiez pas une seule fois. La propagation DNS peut prendre des minutes à des heures. Implémentez un mécanisme de polling :

async function verifyDomain(domain: string, expectedTarget: string): Promise<boolean> {
  try {
    const records = await dns.promises.resolveCname(domain);
    return records.some(r => r === expectedTarget);
  } catch (err) {
    // Pour les enregistrements A (domaines apex)
    try {
      const aRecords = await dns.promises.resolve4(domain);
      return aRecords.some(r => EXPECTED_IPS.includes(r));
    } catch {
      return false;
    }
  }
}

// Polling toutes les 30 secondes pendant jusqu'à 24 heures
async function waitForDNS(domain: string) {
  const maxAttempts = 2880; // 24 heures à intervalles de 30s
  for (let i = 0; i < maxAttempts; i++) {
    if (await verifyDomain(domain, 'custom.yourapp.com')) {
      return true;
    }
    await sleep(30000);
  }
  return false;
}

Étape 3 : Approvisionnement en certificats

Une fois le DNS vérifié, demandez le certificat. Avec Caddy, cela se produit automatiquement à la première requête. Avec nginx/certbot, déclenchez-le programmatiquement.

Étape 4 : Surveillance continue

Les domaines peuvent casser. Les clients changent accidentellement les enregistrements DNS. Les certificats expirent si le renouvellement échoue. Vous devez surveiller :

  • La résolution DNS pointe toujours vers vous (vérifier quotidiennement)
  • Les dates d'expiration du certificat (alerte à 14 jours, critique à 7)
  • Le succès de la poignée de main SSL (surveillance synthétique)
  • Les codes de réponse HTTP sur les domaines clients

Modèles d'infrastructure par plateforme

L'approche varie considérablement selon où vous hébergez.

Vercel

Vercel a un support de domaine personnalisé intégré. Pour une application Next.js multi-locataire, vous utiliseriez son API Domains :

curl -X POST "https://api.vercel.com/v10/projects/{projectId}/domains" \
  -H "Authorization: Bearer $VERCEL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "portal.customer.com"}'

Vercel gère automatiquement le SSL. La principale limitation : vous êtes soumis à leur tarification. Au plan Pro ($20/membre d'équipe/mois), vous obtenez 50 domaines par projet. Enterprise vous en donne plus. Si vous avez des milliers de clients avec des domaines personnalisés, le coût augmente.

Cloudflare pour SaaS (SSL pour SaaS)

C'est probablement la meilleure option pour l'échelle en 2025. Le produit SSL pour SaaS de Cloudflare (anciennement appelé Noms d'hôtes personnalisés) gère tout :

  • Issuance et renouvellement automatiques de certificats
  • CDN global et protection DDoS
  • Vérification de domaine intégrée
  • API pour la gestion programmatique
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/custom_hostnames" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "hostname": "portal.customer.com",
    "ssl": {
      "method": "http",
      "type": "dv"
    }
  }'

Tarification : $0,10/nom d'hôte personnalisé/mois après les 100 premiers (gratuit sur le plan Enterprise). Pour un SaaS avec 1 000 domaines personnalisés, c'est environ $90/mois. Très raisonnable.

AWS (ALB + ACM + Route53)

Si vous êtes sur AWS, vous pouvez utiliser :

  • ALB pour le routage avec sélection de certificat basée sur SNI
  • ACM (AWS Certificate Manager) pour les certificats gratuits
  • Route53 pour la vérification DNS

Le piège : les certificats ACM ne sont utilisables qu'avec les services AWS (ALB, CloudFront, API Gateway). Et ALB a une limite de 25 certificats par équilibreur de charge par défaut (peut être augmenté à 100). Pour une vraie échelle, vous mettriez CloudFront devant avec sa limite de 100 certificats par distribution.

Cela devient coûteux et complexe. J'honnêtement recommanderais Cloudflare pour SaaS plutôt que cette approche sauf si vous avez des exigences AWS spécifiques.

Fly.io

Fly.io a une commande fly certs add agréable et une API pour ajouter des domaines personnalisés :

fly certs add portal.customer.com

Il gère Let's Encrypt automatiquement. Fonctionne bien pour l'échelle petite à moyenne.

Configuration DNS et vérification

La partie DNS bloque plus d'équipes que n'importe quelle autre partie de cette fonctionnalité. Voici ce que vous devez savoir.

Le problème CNAME-à-apex

Les clients voudront inévitablement utiliser leur domaine nu (customer.com, pas de sous-domaine). La spécification DNS n'autorise pas les enregistrements CNAME à l'apex d'une zone car les enregistrements CNAME doivent être exclusifs — ils ne peuvent pas coexister avec d'autres types d'enregistrements, et l'apex a toujours des enregistrements SOA et NS.

Solutions :

  1. Aplatissement CNAME (Cloudflare) — résout le CNAME au niveau DNS, retourne un enregistrement A
  2. Enregistrements ALIAS (Route53, DNSimple) — type d'enregistrement propriétaire qui fonctionne comme un CNAME à l'apex
  3. Enregistrements ANAME (certains fournisseurs) — similaire à ALIAS
  4. Enregistrement A — donnez juste votre adresse IP aux clients

L'option 4 (enregistrements A) est la plus universelle mais la moins flexible. Si vous changez jamais l'IP de votre serveur, chaque client utilisant un enregistrement A doit mettre à jour son DNS. Avec un CNAME, vous mettez juste à jour ce que votre cible CNAME résout.

Ma recommandation : supportez les deux. Dites aux clients d'utiliser un CNAME pour les sous-domaines et un enregistrement A (ou ALIAS/ANAME si leur fournisseur les supporte) pour les domaines apex.

Vérification de propriété

Au-delà de confirmer que le domaine se résout à votre infrastructure, vous pourriez vouloir vérifier que la personne configurant le domaine dans votre SaaS le contrôle réellement. Une approche courante consiste à exiger un enregistrement TXT :

_verification.customer.com  TXT  "yourapp-verify=abc123unique"

Cela empêche quelqu'un de pointer un domaine qu'il ne possède pas vers votre plateforme et de prétendre qu'il appartient à son compte.

Durcissement et surveillance en production

Cette section est la différence entre une démo et un système de production.

Stockage des certificats

Ne stockez pas les certificats sur disque si vous exécutez plusieurs instances. Utilisez un magasin distribué :

  • Caddy : supporte les backends de stockage pour Redis, Consul, S3, PostgreSQL
  • Personnalisé : stockez les certificats dans une base de données chiffrée ou un gestionnaire de secrets (AWS Secrets Manager, HashiCorp Vault)

Secours gracieux

Que se passe-t-il quand le domaine d'un client est mal configuré ? N'affiche pas d'erreur SSL. À la place :

  1. Détectez la poignée de main SSL échouée
  2. Redirigez vers une page de statut expliquant le problème
  3. Envoyez une notification au client
  4. Relancez automatiquement l'approvisionnement en certificats

Vérifications de santé

Constructisez un travail en arrière-plan qui vérifie régulièrement chaque domaine personnalisé :

async function healthCheckDomains() {
  const domains = await db.customDomains.find({ active: true });
  
  for (const domain of domains) {
    const checks = {
      dnsResolves: await checkDNS(domain.hostname),
      sslValid: await checkSSL(domain.hostname),
      httpOk: await checkHTTP(domain.hostname),
    };
    
    if (!checks.dnsResolves) {
      await alertCustomer(domain, 'DNS no longer points to our platform');
      await markDomain(domain, 'dns_error');
    } else if (!checks.sslValid) {
      await triggerCertRenewal(domain);
    }
    
    await db.domainHealthChecks.insert({
      domainId: domain.id,
      ...checks,
      checkedAt: new Date(),
    });
  }
}

Exécutez cela toutes les heures. À 10 000 domaines, les vérifications se terminent en quelques minutes si vous parallélisez correctement.

Analyse des coûts à l'échelle

Parlons des chiffres réels pour la tarification 2025.

Solution 100 domaines 1 000 domaines 10 000 domaines Notes
Caddy + Let's Encrypt (auto-géré) ~50$/mo serveur ~200$/mo serveurs ~1 000$/mo serveurs Votre fardeau opérationnel
Cloudflare pour SaaS Gratuit (Enterprise) ~90$/mo ~990$/mo Meilleur rapport qualité-prix à l'échelle
Vercel (Pro) Inclus 0$ supplémentaires Nécessite Enterprise Limité à 50/projet sur Pro
AWS CloudFront + ACM ~100$/mo ~300$/mo ~2 000$/mo Comprend les coûts de transfert CDN
Fastly ~150$/mo ~500$/mo Tarification personnalisée Bon si vous utilisez déjà Fastly

Pour la plupart des produits SaaS, Cloudflare pour SaaS atteint le point idéal. Vous obtenez un CDN global, une protection DDoS, et des certificats automatisés pour environ un centime par domaine par mois. Difficile à battre cela.

Si vous construisez sur une architecture CMS découplée — quelque chose que nous faisons beaucoup — Cloudflare pour SaaS se couple particulièrement bien car vous gérez déjà des frontends découplés qui bénéficient de la mise en cache edge.

FAQ

Combien de temps faut-il pour qu'un domaine personnalisé devienne actif après la configuration du DNS ?

La propagation DNS prend généralement 5-30 minutes, bien qu'elle puisse prendre jusqu'à 48 heures dans les cas rares. L'approvisionnement en certificats avec Let's Encrypt ajoute 30-60 secondes de plus une fois que la résolution DNS fonctionne correctement. En pratique, la plupart des domaines personnalisés sont pleinement actifs en 15 minutes. Je recommande de faire un polling DNS toutes les 30 secondes et de déclencher l'approvisionnement en certificats immédiatement quand la résolution réussit.

Puis-je utiliser Let's Encrypt pour des milliers de domaines personnalisés sur mon SaaS ?

Oui, mais vous devez planifier autour des limites de débit. La principale contrainte est 50 certificats par domaine enregistré par semaine (pour vos propres sous-domaines de plateforme) et 300 nouvelles commandes par 3 heures. Pour les domaines personnalisés des clients, chaque domaine est un domaine enregistré séparé, donc la limite par domaine ne s'applique pas de la même façon. Vous pouvez aussi demander à Let's Encrypt une augmentation de limite de débit si vous pouvez démontrer un besoin légitime. ZeroSSL est un solide fournisseur ACME de secours.

Quelle est la différence entre les sous-domaines génériques et les domaines personnalisés ?

Les sous-domaines génériques (*.yourapp.com) sont entièrement contrôlés par vous — un enregistrement DNS, un certificat SSL, routage simple. Les domaines personnalisés (portal.customer.com) sont des domaines contrôlés par vos clients, nécessitant qu'ils configurent le DNS et que vous approvisionniez des certificats individuels. La plupart des produits SaaS commencent avec des sous-domaines génériques et ajoutent le support des domaines personnalisés plus tard comme fonctionnalité premium.

Comment je gère les domaines apex (nus) personnalisés ?

Les domaines apex (customer.com sans www) ne peuvent pas utiliser les enregistrements CNAME selon la spécification DNS. Vos options sont : faire créer aux clients des enregistrements A pointant vers votre IP, utiliser des fournisseurs DNS qui supportent les enregistrements ALIAS/ANAME, ou recommander les fournisseurs avec aplatissement CNAME comme Cloudflare. Supportez toujours les deux configurations apex et sous-domaine — les clients voudront les deux.

Devrais-je utiliser Caddy ou nginx pour le SSL automatisé ?

Si vous commencez à zéro, utilisez Caddy. Sa fonctionnalité TLS à la demande a littéralement été construite pour le cas d'usage du domaine personnalisé multi-locataire. Nginx va bien si vous l'avez déjà dans votre pile, mais vous devrez construire plus d'automatisation autour de certbot pour la gestion du cycle de vie des certificats. Caddy gère l'issuance, le renouvellement, le stockage, et l'agrafage OCSP automatiquement.

Comment j'empêche l'abus de ma fonctionnalité de domaine personnalisé ?

Trois couches : D'abord, vérifiez la propriété du domaine avec un enregistrement TXT avant d'accepter un domaine personnalisé. Deuxièmement, implémentez un endpoint "ask" (comme l'ask on_demand_tls de Caddy) qui valide les domaines avant de demander des certificats. Troisièmement, limitez le débit des ajouts de domaines par compte. Sans cela, quelqu'un pourrait pointer des milliers de domaines vers votre IP et consommer vos limites de débit de certificats ou utiliser votre infrastructure pour le domain fronting.

Que se passe-t-il si un client supprime son enregistrement DNS ?

Votre plateforme devrait détecter cela en quelques heures via des vérifications régulières de santé. Quand le DNS arrête de se résoudre vers votre infrastructure, marquez le domaine comme unhealthy, notifiez le client, et arrêtez de tenter le renouvellement du certificat. Ne supprimez pas la configuration du domaine immédiatement — les clients brisent parfois temporairement le DNS pendant les migrations. Je recommande une période de grâce de 30 jours avant de désactiver complètement un domaine personnalisé.

Cloudflare pour SaaS vaut-il le coup comparé à l'auto-gestion des certificats ?

Pour la plupart des produits SaaS, oui. À $0,10/nom d'hôte/mois, le coût est trivial comparé au temps d'ingénierie que vous dépenseriez en construisant et en maintenant l'automatisation des certificats, en gérant les cas limites, en surveillant les renouvellements, et en traitant les limites de débit. Vous obtenez aussi un CDN global et une protection DDoS inclus. La principale raison d'auto-gérer est si vous avez besoin du contrôle total sur votre infrastructure ou d'exigences de conformité spécifiques qui empêchent d'utiliser un proxy tiers. Si vous voulez discuter de l'approche correcte pour votre produit spécifique, contactez-nous — nous avons implémenté les deux modèles.

Les domaines personnalisés sont une de ces fonctionnalités SaaS où le diable est vraiment dans les détails. Le chemin heureux est simple, mais la préparation à la production signifie gérer les délais de propagation DNS, les défaillances de certificats, les erreurs de configuration des clients, et la surveillance à l'échelle. Commencez avec les sous-domaines génériques, ajoutez le support des domaines personnalisés quand les clients le demandent (et ils le feront), et ne cherchez pas à tout construire à partir de zéro quand des outils comme Caddy et Cloudflare pour SaaS existent. Votre futur moi en on-call vous remerciera.