Netzwerk

Über öffentliche Domains und die Per-Request-Regeln in Edge rules hinaus müssen Apps auch privat miteinander sprechen können und manchmal hinter einem CDN eines Drittanbieters stehen oder ein einziges Zertifikat für eine ganze Wildcard-Domain bekommen. Diese Seite deckt diese drei Themen ab.

Privates Networking zwischen Apps

Jede App erhält einen privaten Namen, <name>.railyard.internal, statt dass Apps sich über öffentliche IPs finden müssen:

• Gleicher Server: Der Name ist ein Docker-Netzwerk-Alias, er löst sich also direkt zum Container auf dem eigenen Port der App auf (container_port). Dafür ist kein Setup nötig.
• Anderer Server, privates Netzwerk aus: Ein Verweis auf die andere App funktioniert trotzdem, ist nur nicht privat — er löst sich stattdessen zur normalen öffentlichen https://-Adresse dieser App auf, statt fehlzuschlagen.
• Anderer Server, privates Netzwerk an: Aktiviere es unter Servers → Private network → Turn on (Admins). Jeder Server des Teams tritt einem verschlüsselten WireGuard-Netzwerk bei (10.210.0.0/16), und <name>.railyard.internal löst sich dann von jedem Server des Teams aus dorthin auf, wo die App tatsächlich läuft — über das Mesh, zu ihrem veröffentlichten Port. Der Canvas zeichnet eine solche Verbindung als privat. Bereits laufende Container übernehmen den neuen Resolver bei ihrem nächsten Deploy oder Neustart.

Verweise auf einen anderen Dienst mit ${{api.RAILYARD_PRIVATE_URL}} (für eine App namens api) statt einen Host hart zu kodieren — siehe Variablen und Secrets. Es löst sich zu welchem der obigen Fälle auch immer zutrifft auf, sodass derselbe Verweis weiter funktioniert, falls die beiden Apps später auf unterschiedlichen Servern landen.

Weitere öffentliche Ports

Settings → General → More public ports nimmt pro Zeile ein name:port (z. B. metrics:9100) für ein zweites Protokoll oder eine Admin-Oberfläche auf derselben App. Jeder erhält seine eigene HTTPS-Adresse — <name>-<app-hostname> — geroutet und zertifiziert genauso wie die Hauptadresse der App.

Cloudflare vor einer App

Settings → Networking → Cloudflare setzt Cloudflares CDN, DDoS-Schutz und WAF vor die eigene Plattform-Adresse einer App, wenn der DNS dieser Adresse bereits bei Railyards verwaltetem DNS liegt und dieser DNS auf Cloudflare läuft (nicht Route 53 und nicht eine eigene Domain, für die Railyard die Zone nicht hält — die Karte erklärt, welcher Fall zutrifft).

• Das Aktivieren proxyt den DNS-Record, sobald Railyard ihn das nächste Mal schreibt — beim nächsten Deploy oder einem Failover, nicht sofort.
• Der Edge-Proxy vertraut Cloudflares veröffentlichten IP-Bereichen und liest die echte Besucher-IP aus CF-Connecting-IP, sodass Rate-Limiting, Länder-Sperren, die WAF und Access-Logs weiterhin den tatsächlichen Besucher sehen statt Cloudflares Edge, sobald eine App dies aktiviert — siehe Edge rules.
• HTTPS funktioniert weiter: Railyards eigenes Let’s-Encrypt-Zertifikat wird weiterhin ausgestellt und am Origin ausgeliefert. Setze Cloudflares SSL-Modus auf Full (strict), was dieses Zertifikat prüft, statt zu vertrauen, was der Origin präsentiert.
• Du musst die Nameserver dieser Domain trotzdem selbst auf Cloudflare zeigen lassen — Railyard schreibt immer nur den einen DNS-Record, den es bereits verwaltet, niemals die Nameserver einer Zone.

Wildcard-Zertifikate über DNS-01

Eine Wildcard-Domain (*.example.com, siehe Domains) nutzt standardmäßig On-Demand-TLS: Jede Subdomain erhält beim ersten Besuch ihr eigenes Let’s-Encrypt-Zertifikat, 20 Subdomains bedeuten also 20 Zertifikate. Für ein einziges Zertifikat, das die gesamte Wildcard abdeckt, stattdessen:

1. Team-Einstellungen → DNS credentials → füge ein Cloudflare-API-Token hinzu (beschränkt auf Zone:DNS:Edit für die Zone, nicht den globalen API-Key) oder einen Route-53-Access-Key (route53:ChangeResourceRecordSets und route53:ListResourceRecordSets auf der Hosted Zone). Verschlüsselt gespeichert, nur für die DNS-01-Challenge genutzt.
2. Im Domains-Tab der App zeigt das Hinzufügen oder Bearbeiten einer Wildcard-Adresse ein DNS credential-Dropdown. Wähle eines, um ein einziges Wildcard-Zertifikat anzufordern; lass es leer, um das On-Demand-Verhalten zu behalten.

Das Entfernen eines Credentials lässt dessen Wildcard-Domains auf On-Demand-Zertifikate zurückfallen, statt sie zu brechen.

Ausgehender Traffic

Die ausgehenden Verbindungen einer App verlassen die öffentliche IP ihres eigenen Servers — es gibt keinen gemeinsamen NAT-Pool und keine Extra-Kosten für eine stabile Adresse, um sie in die IP-Allowlist einer Drittanbieter-API einzutragen, wie es eine Multi-Tenant-Plattform bräuchte. Die IP ändert sich nur, wenn die App selbst auf einen anderen Server umzieht.

Siehe auch

• Domains — die Standardadresse, eigene Domains und der Besitznachweis.
• Edge rules — Per-Request-Regeln: Redirects, Header, CORS, Rate-Limiting, Länder-Sperren, die WAF.
• Variablen und Secrets — Verweis auf die private URL eines anderen Dienstes.
• Add a server — das private Netzwerk aktivieren.