Um IP de saída estável, sem conta de NAT gateway
Todo PaaS multi-tenant bate na mesma pedra eventualmente: a API de um banco, um processador de pagamento, uma integração de parceiro — algo do outro lado quer um endereço IP fixo numa allowlist antes de conversar com o seu app. Numa plataforma onde centenas de apps compartilham um pool de endereços de saída, isso significa montar um NAT gateway, muitas vezes um add-on pago, às vezes um nível de produto separado, só para ter um endereço que fica fixo.
Por que o problema não existe aqui
As conexões de saída de um app saem do próprio IP público do seu servidor — porque o servidor não é compartilhado com o app de mais ninguém, não existe um pool para fazer NAT através dele, para começar. Sem pool de NAT compartilhado, sem cobrança extra por um endereço estável, sem recurso separado para ativar. O IP só muda se o próprio app de fato se mover para um servidor diferente — um evento real do qual você saberia, não uma reorganização silenciosa do lado da plataforma.
Isso não é um recurso que o Railyard construiu para resolver o problema do NAT gateway. É uma consequência estrutural do modelo BYO-server: a coisa que torna um IP de saída estável caro em outro lugar (infraestrutura compartilhada) simplesmente não existe aqui.
Onde de fato encontrar o endereço
A própria página do servidor mostra o IP público dele diretamente — esse é o endereço para entregar a qualquer serviço de terceiros que precise colocá-lo numa allowlist. Se o app algum dia se mover (uma movimentação manual, ou um failover automático), o IP muda junto, o que vale incluir em qualquer runbook de uma integração de parceiro que dependa disso: trate o IP de saída como atrelado ao servidor, não como uma propriedade do app que o segue para todo lugar.
O problema adjacente que isso não resolve
Um IP de saída estável para conversar para fora com terceiros é um problema diferente de apps conversando entre si de forma privada — é para isso que existe a rede privada: todo app recebe <name>.railyard.internal, resolvido por uma malha WireGuard criptografada quando os apps estão divididos entre servidores, então um app referencia outro pelo nome em vez de qualquer endereço público ou privado que ele tenha hoje. Os dois recursos resolvem problemas genuinamente diferentes e não substituem um ao outro — estabilidade de saída é sobre o que um terceiro vê; rede privada é sobre o que os seus próprios apps veem.
Referência completa: Networking.