Réseau privé et domaines .internal sur Dockup

Le réseau privé permet aux services et aux bases de données gérées d’un même projet Dockup de communiquer sans faire transiter le trafic entre ressources du projet par l’Internet public. Chaque ressource reçoit un hostname stable au format <slug>.internal, tandis que les projets distincts restent isolés les uns des autres.

Le réseau est activé de manière opt-in. Son activation connecte les ressources existantes du projet sans obliger immédiatement le trafic applicatif à changer de chemin, et les services reçoivent les variables de connexion internes après un redeploy.

Comment le réseau service-à-service réduit-il l’exposition publique ?

Un endpoint de base de données public est accessible depuis Internet, même lorsque l’authentification bloque les utilisations non autorisées. Une route privée supprime cette exposition pour le trafic applicatif et fournit aux services un nom interne stable qui ne dépend pas d’une adresse publique.

Le même principe s’applique aux appels service-à-service. Une API peut appeler un worker, un service d’administration interne ou un backend via le réseau du projet plutôt que par un domaine public personnalisé.

Chemin du trafic	Route publique	Route privée
API vers PostgreSQL	Hôte et port publics	main-db.internal
Web vers API	Domaine public personnalisé	api.internal
Worker vers Redis	Hôte et port publics	app-redis.internal
Preview vers la base de production	Identifiants publics de la base	Utilisateur interne en lecture seule
Appel interprojets	Endpoint public requis	Bloqué par l’isolation des projets

Privé ne signifie pas non authentifié. Continuez à utiliser des utilisateurs de base de données, l’autorisation des services et des secrets. Le réseau détermine l’accessibilité ; les identifiants déterminent les permissions.

Comment activer le réseau privé d’un projet ?

Activez le réseau pour le slug du projet :

dockup network enable production --json

Cette opération connecte les services et les bases de données gérées au réseau du projet. Les listeners publics existants restent disponibles par défaut, ce qui permet une adoption progressive.

Redeployez chaque service applicatif qui doit recevoir les variables d’environnement internes :

dockup deploy production/api --wait --json
dockup deploy production/worker --wait --json

Dockup injecte des données de connexion telles que DATABASE_URL_INTERNAL, des variables d’URL et d’hôte internes spécifiques à la base de données, ainsi que les valeurs d’hôte et de port des services. Inspectez les clés de l’environnement du service sans exposer les secrets :

dockup env list -s production/api --json

Ne construisez pas manuellement une URL à partir d’un nom d’affichage. Les resource slugs déterminent le hostname <slug>.internal.

Avant de modifier la configuration de l’application, vérifiez que chaque dépendance se trouve dans le même projet. Les projets distincts disposent de réseaux séparés et ne peuvent ni résoudre ni atteindre les uns les autres via le chemin interne.

Comment les domaines .internal modifient-ils la configuration des services ?

Le DNS interne fournit un nom stable, même lorsque les conteneurs et les nodes changent en arrière-plan. Un service API dont le slug est api est accessible sous api.internal depuis les services du même projet ; une base de données dont le slug est main-db est accessible sous main-db.internal.

Privilégiez les variables de connexion injectées lorsqu’elles sont disponibles. Elles encodent le protocole, les identifiants, le nom de la base de données et le format d’hôte corrects. Une chaîne construite manuellement peut omettre TLS, l’encodage du mot de passe ou certains paramètres de base de données.

Migrez une dépendance à la fois :

1. Activez le réseau.
2. Redeployez le service consommateur.
3. Vérifiez que la variable interne existe.
4. Modifiez l’application pour qu’elle l’utilise.
5. Déployez avec --wait.
6. Vérifiez les nouvelles connexions.
7. Surveillez les logs d’exécution et le temps de réponse.
8. Passez à la dépendance suivante.

Un service peut conserver son domaine public personnalisé pour le trafic utilisateur tout en utilisant des hostnames privés pour les appels backend. Les chemins public et privé correspondent à des périmètres de confiance différents.

Le guide variables d’environnement et secrets explique pourquoi les changements de connexion nécessitent un redeploy.

Comment rendre une base de données gérée accessible uniquement en privé ?

Une fois que tous les consommateurs requis utilisent le chemin interne, supprimez le listener public :

dockup db private production/main-db --json

Restaurez l’accès public et privé lorsque cela est nécessaire :

dockup db private production/main-db --off --json

Cette opération sur la base de données recrée le conteneur tout en préservant les données. Prévoyez une fenêtre de maintenance adaptée à la charge, vérifiez qu’une sauvegarde récente existe et testez la reconnexion de l’application.

Avant de la rendre accessible uniquement en privé, vérifiez les points suivants :

• Chaque service de production utilisant la base se trouve dans le même projet.
• Les outils opérationnels n’ont pas besoin de l’endpoint public.
• L’accès des previews utilise le chemin privé pris en charge.
• Une sauvegarde existe et la procédure de restauration est maîtrisée.
• Les connection pools réessaient les connexions de manière sûre.
• La cible exacte project/db est consignée.

Une base de données accessible uniquement en privé ne peut pas être atteinte directement depuis l’ordinateur portable d’un opérateur via l’Internet public. Utilisez les mécanismes d’accès pris en charge par la plateforme et les diagnostics au niveau de l’application plutôt que de rouvrir le listener de manière irréfléchie.

Pour les opérations sur les bases de données, consultez PostgreSQL géré.

Comment les PR previews accèdent-elles aux données de production en toute sécurité ?

Chaque preview de PR ou de branche Dockup reçoit un déploiement et une URL isolés. Dans un projet utilisant le réseau privé, la preview rejoint le réseau du projet et peut résoudre <slug>.internal.

Dockup crée automatiquement un utilisateur en lecture seule pour la base de données gérée de production utilisée par la preview. La preview peut interroger des données représentatives de la production, mais ne peut pas écrire avec cet utilisateur.

Cette conception réduit le risque qu’une feature branch modifie des fiches client, mais l’accès en lecture a tout de même des conséquences :

• Des données personnelles ou sensibles peuvent apparaître dans la preview.
• Du nouveau code applicatif peut journaliser les données interrogées.
• Une URL de preview vulnérable peut exposer les résultats des requêtes.
• Des requêtes coûteuses peuvent affecter la charge de production.
• Les hypothèses concernant le schéma peuvent différer entre la branche et la production.

N’activez le déploiement des previews que dans le cadre d’une politique validée :

dockup pr-preview production/api --on --json
dockup preview branch feature/search production/api --json

Utilisez l’environnement isolé de la preview pour les feature flags et les secrets qui ne concernent pas la base de données. Ne remplacez pas l’identifiant automatique en lecture seule par l’identifiant de production autorisant les écritures.

Comment observer et dépanner le réseau privé ?

Commencez par la topologie et la configuration plutôt que de supposer une panne de la plateforme.

Symptôme	Domaine probablement concerné	Vérification
Nom introuvable	Slug ou projet incorrect, ou service non redeployé	Liste des services et clés d’environnement
Connexion refusée	Ressource arrêtée ou port incorrect	Statut et logs de la base ou du service
Échec de l’authentification	Identifiant incorrect	Rotation du secret et utilisateur
Le public fonctionne, le privé échoue	Variable interne ou adoption du réseau	Activation du réseau, redeploy
La preview peut lire mais pas écrire	Politique attendue en lecture seule	Ne remplacez pas l’identifiant
L’appel interprojets échoue	Isolation attendue	Utilisez une API publique authentifiée

Inspectez les logs d’exécution de l’application :

dockup logs production/api --json

Inspectez la taille de la base de données et les erreurs de connexion de l’application :

dockup db size production/main-db --json
dockup logs production/api --json

N’affichez pas les URL de connexion internes complètes dans les notes d’incident. Elles peuvent contenir des identifiants, même si le hostname lui-même n’est pas un secret.

Plan de migration et de rollback

Conservez le listener public pendant la première phase. Si le déploiement interne échoue, restaurez la configuration précédente de l’application et redeployez. Ne rendez la base accessible uniquement en privé qu’après avoir stabilisé le chemin interne.

Pour désactiver le réseau de l’ensemble du projet :

dockup network disable production --json

Cette opération doit constituer un rollback réfléchi, et non la première étape du dépannage. La désactivation du réseau affecte toutes les ressources connectées du projet.

Consignez les modifications du réseau via l’audit log :

dockup audit --writes --json

Checklist de production du réseau privé

Un runbook complet du réseau privé comprend le slug du projet, les slugs des services et des bases de données, les hostnames internes, les noms des variables injectées, la politique concernant les listeners publics, la politique d’accès des previews, l’état des sauvegardes, l’ordre des redeploys et le chemin de rollback.

Le CPU, la RAM et le disque restent facturés selon l’usage et mesurés à la minute ; le routage privé est un choix d’architecture, pas une classe d’instance fixe. Utilisez Comprendre la tarification des PaaS pour modéliser les coûts.

La référence de la Dockup CLI contient les commandes actuelles pour le réseau et les bases de données. Pour l’isolation générale des déploiements, consultez les bonnes pratiques de sécurité.

Modéliser séparément l’autorisation des services et l’accessibilité

Un hostname interne prouve uniquement que l’appelant se trouve sur le réseau du projet. Il ne prouve ni quel service a effectué la requête ni si ce service est autorisé à réaliser l’action. Conservez l’authentification applicative pour les API internes sensibles et les identifiants de base de données pour l’accès aux données.

Utilisez des secrets propres à chaque service plutôt qu’un token interne partagé. Si une preview reçoit un accès en lecture seule à la base de données, ne lui attribuez pas également un token de service de production capable de déclencher des écritures via une API.

Mesurer l’effet du basculement

Comparez la latence des connexions, le taux d’erreur et le temps de réponse p95 avant et après le passage aux endpoints internes. L’objectif principal est l’isolation et un chemin privé stable ; toute amélioration de la latence doit être mesurée plutôt que promise.

dockup uptime production/api --hours 24 --json

Conservez la fenêtre d’observation et l’ID du déploiement. La modification du réseau privé dispose ainsi d’un critère d’achèvement mesurable au lieu de s’arrêter à « le DNS a répondu ».

Documenter l’exception au chemin public

Certaines intégrations externes, certains outils opérateur ou certains services interprojets peuvent encore nécessiter un endpoint public. Répertoriez chaque exception, son authentification, son responsable et sa condition de suppression. Cela évite qu’un listener public reste indéfiniment actif parce que personne ne se souvient de sa raison d’être.

Un déploiement complet du réseau privé peut être partiel, mais chaque chemin public doit être intentionnel.

Revoir les dépendances internes après un renommage

Le renommage ou le remplacement d’une ressource peut modifier le slug utilisé pour l’adressage .internal. Répertoriez les consommateurs avant de modifier les noms, redeployez-les avec les variables injectées mises à jour et vérifiez chaque connexion privée.

Le réseau privé reste ainsi stable à mesure que le projet évolue.

Commencer par un déploiement vérifiable

Activez le réseau dans un projet non productif, migrez une dépendance vers son endpoint .internal et validez le chemin de rollback avant de supprimer un listener public.

Commencez gratuitement sur app.dockup.ai. Le forfait Free coûte 0 $ par mois, comprend un crédit initial de 10 $ et prend en charge un workspace, trois bases de données et trois déploiements.

FAQ

Quel hostname les ressources Dockup utilisent-elles sur le réseau privé ?

Chaque service et chaque base de données gérée du même projet sont accessibles via un hostname stable au format <slug>.internal.

L’activation du réseau privé supprime-t-elle l’accès public à la base de données ?

Non. Le réseau est additif par défaut. Utilisez la commande privée distincte de la base de données pour supprimer le listener public une fois que les consommateurs utilisent le chemin interne.

Des projets Dockup différents peuvent-ils communiquer entre eux en privé ?

Non. Chaque projet possède un réseau isolé ; la communication interprojets doit donc utiliser une interface publique et authentifiée appropriée.

Une PR preview peut-elle écrire dans la base de données de production ?

Dans un projet utilisant le réseau privé, Dockup provisionne automatiquement un utilisateur de base de données en lecture seule pour la preview, ce qui autorise les lectures mais empêche les écritures avec cet identifiant.

Pourquoi les services doivent-ils être redeployés après l’activation du réseau ?

Le redeploy fournit au nouveau conteneur les variables de connexion internes et permet à l’application de démarrer avec la configuration de l’endpoint privé.