Une IP sortante stable, sans facture de passerelle NAT
Chaque PaaS multi-locataire rencontre la même demande tôt ou tard : une API bancaire, un processeur de paiement, une intégration partenaire — quelque chose de l’autre côté veut une adresse IP fixe à mettre sur liste blanche avant d’accepter de parler à votre application. Sur une plateforme où des centaines d’applications partagent un bassin d’adresses sortantes, ça veut dire monter une passerelle NAT, souvent un module payant, parfois son propre palier de produit séparé, juste pour obtenir une adresse qui reste fixe.
Pourquoi le problème n’existe pas ici
Les connexions sortantes d’une application partent de la propre IP publique de son serveur — parce que le serveur n’est partagé avec l’application de personne d’autre, il n’y a pas de bassin à travers lequel faire du NAT au départ. Pas de bassin NAT partagé, pas de frais supplémentaires pour une adresse stable, pas de fonctionnalité séparée à activer. L’IP ne change que si l’application elle-même se déplace vraiment vers un autre serveur — un vrai événement dont vous seriez informé, pas un remaniement silencieux côté plateforme.
Ce n’est pas une fonctionnalité que Railyard a construite pour résoudre le problème de la passerelle NAT. C’est une conséquence structurelle du modèle « apportez votre propre serveur » : la chose qui rend une IP sortante stable coûteuse ailleurs (infrastructure partagée) n’est tout simplement pas présente ici.
Où trouver vraiment l’adresse
La propre page du serveur montre son IP publique directement — c’est l’adresse à remettre à n’importe quel service tiers qui a besoin de la mettre sur liste blanche. Si l’application se déplace un jour (un déplacement manuel, ou un basculement automatique), l’IP change avec elle, ce qui mérite d’être intégré à tout plan de reprise pour une intégration partenaire qui en dépend : traitez l’IP sortante comme liée au serveur, pas comme une propriété de l’application qui la suit partout.
Le problème voisin que ça ne résout pas
Une IP sortante stable pour parler vers l’extérieur à des tiers est un problème différent de celui des applications qui se parlent entre elles en privé — c’est à ça que sert le réseau privé : chaque application reçoit <name>.railyard.internal, résolu sur un maillage WireGuard chiffré quand les applications sont réparties sur plusieurs serveurs, pour qu’une application en référence une autre par son nom plutôt que par l’adresse publique ou privée qu’elle a aujourd’hui. Les deux fonctionnalités résolvent des problèmes vraiment différents et ne se substituent pas l’une à l’autre — la stabilité sortante concerne ce qu’un tiers voit; le réseau privé concerne ce que vos propres applications voient.
Référence complète : Réseau.