Serverwartung

Betriebssystem-Updates

Jede Serverseite hat eine Betriebssystem-Karte. Railyard meldet ausstehende Updates innerhalb einer halben Stunde nach dem Verbinden des Servers und danach täglich: wie viele insgesamt, wie viele davon Sicherheitsupdates sind, und ob ein Neustart nötig ist.

• Alle Updates installieren oder Sicherheitsupdates installieren und neu starten. Ein Update kann Docker neu starten, sodass Apps für ein paar Sekunden flackern können; ein Neustart legt die Apps des Servers für etwa eine Minute lahm.
• Nächtliche Sicherheitsupdates werden unbeaufsichtigt angewendet; ein Neustart wird dabei nie automatisch durchgeführt.
• Das Badge verschwindet, sobald der Server neu gestartet wurde.

Postgres-Hauptversions-Upgrades

Ein verwaltetes Postgres kann von 16 auf 17 oder 18 wechseln, direkt über seine Karte. Railyard prüft zuerst die Kompatibilität, erstellt ein Backup, führt das Upgrade an Ort und Stelle durch und verifiziert die Tabellenanzahl. Die alte Version bleibt sieben Tage erhalten, damit du zurückrollen kannst. Neue Datenbankserver nutzen standardmäßig Postgres 17.

Point-in-Time-Recovery

Maintenance → Point-in-time recovery → Turn on archiviert jedes WAL-Segment und ein Basis-Backup für das Postgres des Servers im Backup-Speicher deines Teams, sodass jede Datenbank darauf auf jede Sekunde der letzten 7 Tage zurückgebaut werden kann.

Um wiederherzustellen, öffne die Konsole der Datenbank (App → Resources → Database-Karte → Console) und nutze den Tab Restore to a time: wähle eine Sekunde innerhalb des archivierten Zeitfensters, dann entweder Into a new copy (<db>_at_YYYYMMDDHHMM, dort prüfen und zurückkopieren, was du brauchst) oder Replace the live database (alles nach diesem Zeitpunkt geht verloren). Die Wiederherstellung benötigt denselben Backup-Speicher, der auch für reguläre Backups verwendet wird.

Snapshots

Erstelle vor einer Größenänderung oder einem OS-Upgrade einen Provider-Snapshot über die Serverseite und stelle ihn wieder her, falls etwas schiefgeht. Snapshots werden von deinem Cloud-Provider verwaltet und von diesem abgerechnet.

Gehärtete Isolation (Beta)

Unter Settings → General einer App schärfen zwei opt-in, standardmäßig ausgeschaltete Einstellungen die Container-Grenze zwischen Apps, die sich einen Server teilen:

• Hardened isolation: Der Container der App läuft als eigene Non-Root-UID mit entfernten Capabilities und einem eigenen Docker-Netzwerk, sodass er keine andere App auf dem Server erreichen kann und selbst nicht erreichbar ist. Teste das zuerst – es kann ein Image zerstören, das Root benötigt.
• Read-only filesystem: Mountet das Root-Dateisystem des Containers read-only mit einem schreibbaren /tmp. Nur aktivieren, wenn geprüft wurde, dass die App nirgendwo sonst schreibt.

Beide greifen erst beim nächsten Deploy. Jeder Server teilt sich weiterhin einen Kernel; sandboxed-runtime-Isolation (gVisor) steht auf der Roadmap, ist aber noch nicht umgesetzt.

Sicherheits-Score

Settings → Security bewertet das Team anhand einer Checkliste von 0 bis 100, mit einem Fix-Link pro Punkt; die vollständige Liste findest du unter Teams, SSO und Zugriff. Jede Verbindung zu deinem Server ist über TLS authentifiziert, mit Zugangsdaten, die eindeutig für diesen Server sind.