Una IP de salida estable, sin factura de NAT gateway
Todo PaaS multi-tenant se topa tarde o temprano con la misma solicitud: la API de un banco, un procesador de pagos, una integración con un socio —algo al otro lado quiere una dirección IP fija para poner en lista blanca antes de hablar con tu app. En una plataforma donde cientos de apps comparten un conjunto de direcciones de salida, eso significa levantar un NAT gateway, muchas veces un complemento de pago, a veces todo un nivel de producto separado, solo para conseguir una dirección que se quede fija.
Por qué el problema simplemente no existe aquí
Las conexiones salientes de una app salen desde la IP pública propia de su servidor —porque el servidor no se comparte con la app de nadie más, de entrada no hay ningún conjunto por el que hacer NAT. Sin pool de NAT compartido, sin cargo extra por una dirección estable, sin función separada que activar. La IP solo cambia si la app en sí se mueve de verdad a otro servidor —un evento real del que te enterarías, no una reorganización silenciosa del lado de la plataforma.
Esto no es una función que Railyard construyó para resolver el problema del NAT gateway. Es una consecuencia estructural del modelo de servidor propio: lo que hace cara una IP de salida estable en otras partes (infraestructura compartida) simplemente no existe aquí.
Dónde encontrar realmente la dirección
La página propia del servidor muestra directamente su IP pública —esa es la dirección que le das a cualquier servicio de terceros que necesite ponerla en lista blanca. Si la app alguna vez se mueve (un traslado manual, o un failover automático), la IP cambia con ella, lo cual vale la pena incorporar a cualquier runbook de una integración con un socio que dependa de esto: trata la IP de salida como algo ligado al servidor, no como una propiedad de la app que la sigue a todas partes.
El problema cercano que esto no resuelve
Una IP de salida estable para hablar hacia afuera con terceros es un problema distinto al de las apps hablando entre sí en privado —para eso está la red privada: cada app recibe <name>.railyard.internal, resuelto sobre una malla WireGuard cifrada cuando las apps están repartidas entre servidores, de modo que una app referencia a otra por nombre en vez de por la dirección pública o privada que tenga hoy. Las dos funciones resuelven problemas genuinamente distintos y no se sustituyen entre sí —la estabilidad de salida tiene que ver con lo que ve un tercero; la red privada tiene que ver con lo que ven tus propias apps.
Referencia completa: Redes.