Eine stabile ausgehende IP, ohne NAT-Gateway-Rechnung
Jede Multi-Tenant-PaaS stößt irgendwann auf dieselbe Anfrage: die API einer Bank, ein Payment-Prozessor, eine Partner-Integration – irgendetwas auf der anderen Seite will eine feste IP-Adresse auf der Allowlist haben, bevor es mit deiner App spricht. Auf einer Plattform, auf der sich hunderte Apps einen Pool ausgehender Adressen teilen, bedeutet das, ein NAT-Gateway aufzusetzen – oft ein kostenpflichtiges Add-on, manchmal eine eigene separate Produktstufe, nur um eine Adresse zu bekommen, die stabil bleibt.
Warum das Problem hier nicht existiert
Die ausgehenden Verbindungen einer App verlassen diese über die eigene öffentliche IP ihres Servers – weil der Server mit niemandes anderer App geteilt wird, gibt es von vornherein keinen Pool, durch den man NATen müsste. Kein geteilter NAT-Pool, keine Extrakosten für eine stabile Adresse, kein separates Feature zum Aktivieren. Die IP ändert sich nur, wenn die App selbst tatsächlich auf einen anderen Server umzieht – ein echtes Ereignis, von dem du wüsstest, keine stille Umschichtung seitens der Plattform.
Das ist kein Feature, das Railyard gebaut hat, um das NAT-Gateway-Problem zu lösen. Es ist eine strukturelle Konsequenz des BYO-Server-Modells: Das, was eine stabile ausgehende IP anderswo teuer macht (geteilte Infrastruktur), gibt es hier schlicht nicht.
Wo du die Adresse tatsächlich findest
Die eigene Seite des Servers zeigt direkt seine öffentliche IP – das ist die Adresse, die du einem beliebigen Drittanbieter-Dienst gibst, der sie auf der Allowlist braucht. Wenn die App jemals umzieht (ein manueller Umzug oder ein automatisches Failover), ändert sich die IP mit – ein Punkt, der in jedes Runbook für eine Partner-Integration gehört, die davon abhängt: Behandle die ausgehende IP als an den Server gebunden, nicht als Eigenschaft der App, die ihr überallhin folgt.
Das benachbarte Problem, das das nicht löst
Eine stabile ausgehende IP, um nach außen mit Dritten zu sprechen, ist ein anderes Problem als Apps, die untereinander privat sprechen – dafür gibt es privates Netzwerk: Jede App bekommt <name>.railyard.internal, aufgelöst über ein verschlüsseltes WireGuard-Mesh, wenn Apps über mehrere Server verteilt sind, sodass eine App eine andere beim Namen referenziert, statt über die öffentliche oder private Adresse, die sie gerade zufällig hat. Die beiden Features lösen wirklich unterschiedliche Probleme und ersetzen sich nicht gegenseitig – ausgehende Stabilität betrifft, was ein Dritter sieht; privates Netzwerk betrifft, was deine eigenen Apps sehen.
Vollständige Referenz: Netzwerk.