Edge-Regeln

Jeder Server betreibt einen Web-Proxy vor seinen Apps. Die folgenden Regeln laufen dort, bevor eine Anfrage deine App erreicht. Die meisten davon leben im Tab Settings → Networking der App und greifen beim nächsten Deploy.

Du kannst sie auch über die API setzen (GET / PATCH /api/applications/:id/edge, das die gesendeten Keys zusammenführt) oder im Abschnitt edge: von railyard.yml.

Zugriff: Passwort und IP-Regeln

Die Karte Access macht drei Dinge:

• Passwort. Setzt ein Passwort auf die App, passend für Stagings, Previews und Admin-Tools.
• IP-Regeln. Erlaube oder verweigere eine Adresse oder einen CIDR-Bereich pro Zeile. Alle anderen bekommen 403.
• Kein Indexieren. Standard- und Preview-Adressen sagen Suchmaschinen bereits, sie nicht zu indexieren.

HTTPS

Jede Adresse erhält ein Zertifikat, und ein einfacher HTTP-Besuch wird standardmäßig auf HTTPS umgeleitet. Schalte HTTP redirects to HTTPS nur für Clients aus, die einem Redirect nicht folgen können, etwa alte Geräte oder Health-Checker — die App antwortet dann auch auf reinem HTTP. Greift beim nächsten Deploy.

Redirects und Rewrites

Redirects and rewrites nimmt eine Regel pro Zeile. Regeln werden in der angegebenen Reihenfolge geprüft, und der erste Treffer gewinnt:

/blog/* https://blog.example.com/*{?query} 301
www.shop.example.com/promo /sale 302
/old-api/* /api rewrite
/legacy /new

• Typ: 301, 302, 307, 308 oder rewrite. Standardmäßig 301.
• Host: Ein Host vor dem Pfad beschränkt die Regel auf diese Adresse.
• Nachgestelltes *: Trägt den Rest des Pfads mit über.
• Rewrites liefern einen anderen Pfad derselben App aus und behalten den Query-String.

Du kannst bis zu 100 Regeln haben. Sie sind während des Maintenance-Modus deaktiviert.

Response-Header und CORS

Response headers and CORS nimmt eine Header-Regel pro Zeile:

* X-Frame-Options: DENY
/api/* Cache-Control: no-store
* -X-Powered-By

Ein von dir gesetzter Header ersetzt den Wert, den deine App gesendet hat, und -Name entfernt den Header. Du kannst bis zu 50 Regeln haben.

Für CORS liste die erlaubten Origins auf, dann die Methoden, die Header, ob Credentials erlaubt sind, und ein Max-Age. Der Proxy beantwortet Preflight-Anfragen selbst, sie erreichen die App also nie, und andere Origins erhalten keine CORS-Header. Hat die App ein Passwort, bekommen Preflights 401.

Fehler- und Maintenance-Seiten

• Fehlerseite: Wird mit dem echten Status (502, 503 oder 504) angezeigt, wenn die App nicht antworten kann, weil sie abgestürzt ist, neu startet oder zu langsam ist.
• Maintenance-Seite: Ersetzt Railyards eingebaute Seite, während der Maintenance-Modus aktiv ist. Wird weiterhin mit 503 gesendet.

Füge das HTML ein, oder gib eine Adresse an, und Railyard kopiert die Seite bei jedem Speichern. Eine kopierte Seite kann bis zu 64 KB groß sein und muss auf einer öffentlichen Adresse liegen. Seiten werden so ausgeliefert, wie sie sind, verwende also vollständige URLs für Bilder und Styles. Die Karte hat einen Vorschau-Link.

Pfad-Routing

Path routing liefert diese App unter einem Pfad der Adresse einer anderen App aus, etwa shop.example.com/api für deine API, auf einem Zertifikat. Du kannst das Präfix behalten oder entfernen.

Beide Apps müssen auf dem gleichen Server laufen. Routing über Server hinweg wird noch nicht unterstützt.

Dein eigenes SSL-Zertifikat

Settings → Domains → Your own certificates. Füge ein PEM-Zertifikat samt Chain und einen unverschlüsselten PEM-Key ein. Vor dem Speichern prüft Railyard, dass:

• der Key zum Zertifikat passt;
• das Zertifikat derzeit gültig ist;
• es mindestens eine der Adressen der App abdeckt.

Zertifikat und Key werden verschlüsselt gespeichert, und die API gibt den Key nie zurück. Die Karte zeigt das Ablaufdatum, und Railyard sendet 14 Tage vor Ablauf über die App-down-Regeln der App eine Warnung. Sobald es abläuft, wechselt der nächste Deploy zurück zu automatischen Let’s-Encrypt-Zertifikaten. Zertifikate können nicht in railyard.yml stehen, weil das einen privaten Key in Git ablegen würde.

API: GET / POST /api/applications/:id/certificates, DELETE …/certificates/:cert_id.

Rate-Limiting (Beta)

Rate limiting setzt Requests pro Minute pro Client-IP. Du kannst ein Limit für die ganze App festlegen und zusätzlich Limits pro Pfad hinzufügen:

Whole app: 600
/login 10
/api/* 120

Eine Anfrage über dem Limit bekommt 429 mit Retry-After.

Beta: Rate-Limits benötigen Railyards eigenes Edge-Proxy-Image auf dem Server, und dieses Image wird noch ausgerollt. Solange dein Server es nicht hat, werden die Regeln gespeichert, aber nicht angewendet, und sowohl die Karte als auch das Deploy-Log weisen darauf hin.

Weitere Grenzen:

• Zähler leben im Speicher jedes einzelnen Servers, sodass eine App auf mehreren Servern das Limit pro Server erhält.
• Hinter Cloudflare oder einem anderen Proxy sieht jeder Besucher wie die IP dieses Proxys aus, und vertrauenswürdige Proxys können noch nicht konfiguriert werden.

Länder-Sperren (Beta)

Countries nimmt zweistellige Ländercodes in zwei Listen auf, allow only und block. UNK deckt Adressen mit unbekanntem Land ab.

• Gesperrte Besucher bekommen 403, noch vor Rate-Limits, Redirects oder deiner App.
• Private und interne Adressen kommen immer durch.
• Die Länderdaten stammen von DB-IP Lite.

Dies benötigt dasselbe Edge-Proxy-Image wie Rate-Limiting, daher werden die Regeln heute gespeichert, aber nicht angewendet. Dieselbe Cloudflare-Einschränkung gilt.

Web Application Firewall (Beta)

Web application firewall führt jede Anfrage durch das OWASP Core Rule Set (SQL-Injection, XSS und die anderen CRS-Kategorien), bevor sie die App erreicht. Setze den Modus: Off (keine Prüfungen), Detect (protokolliert, blockiert nie — nutze das zuerst, um zu sehen, was gestoppt worden wäre) oder Block (durchgesetzt, gibt 403 zurück). Greift beim nächsten Deploy; eine blockierte Anfrage erscheint in den Logs der App wie jeder andere Edge-Block.

Dies benötigt dasselbe Edge-Proxy-Image wie Rate-Limiting und Länder-Sperren, daher ist die Einstellung bis dein Server es hat gespeichert, aber nicht angewendet, und die Karte weist darauf hin.

Cloudflare und privates Networking

Cloudflares CDN und WAF vor die eigene Adresse einer App zu setzen, das private Mesh zwischen Apps und ein einziges Zertifikat für eine ganze Wildcard-Domain sind in Networking beschrieben.

Eigene Domains

Domains hinzufügen, www- und Bare-Domain-Paare, Wildcard-Subdomains und der Besitznachweis sind in Domains beschrieben.