Was wir ausgeliefert haben, neueste zuerst.

railyard apps:rm <app> löscht eine App aus der CLI, aber nur mit --confirm <app-name>, das zum eigenen Namen der App passt — dasselbe Muster mit eingetippter Bestätigung, das das Dashboard schon für destruktive Aktionen nutzt, sodass ein Deploy-Skript nicht aus Versehen bei einem Tippfehler die falsche App löscht.

Wir haben einen Live-Verifizierungslauf über Dutzende Community-App-Templates gemacht — Immich, Affine, MediaCMS, Supabase, Dify, Appwrite, LibreChat, Seafile, Rocket.Chat, PostHog, LogChimp, Castopod, Zulip, Airbyte, Langfuse und andere — und behoben, was ein echter Deploy tatsächlich aufgedeckt hat: fehlende Umgebungsvariablen, falsche Standard-Ports, und eine Handvoll Launch-Key-Kollisionen, bei denen zwei Templates denselben Identifier teilten.

Im selben Durchlauf drei Fixes auf Plattformebene, die im Alltag nie sichtbar waren, aber einen Server eher sich selbst heilen lassen statt einen manuellen Anstoß zu brauchen: ein Server, der Storage auf einem unerwarteten Device-Pfad anhängte, ein Routing-Watchdog, der zu eifrig neu startete, und eine DNS-Änderung, die ihre Abhängigen nicht immer mitbekommen haben. Durchstöbere den Template-Katalog.

Jeder kann sich jetzt ohne Einladung registrieren. Neue Teams starten im Free-Plan (1 Server, 3 Apps) mit 14 Tagen Pro, ohne Kreditkarte. Pro und Team sind flache Preise pro Team ohne Nutzungsabrechnung; Teams, die vor heute beigetreten sind, behalten Pro kostenlos. Preise, Docs.

Eine unabhängige Sicherheitsüberprüfung führte zu einer engeren Begrenzung von API-Tokens, strengeren Prüfungen bei ausgehenden Requests und Hostnamen, und keinen Previews mehr für Pull Requests aus Forks. Wir haben außerdem mehrere kleinere Probleme bei der App-Erstellung, bei Deploy-Status-Updates und auf den öffentlichen Seiten behoben.

Der Proxy vor jeder App übernimmt jetzt, was du sonst in Nginx konfigurieren würdest, direkt aus den Einstellungen → Netzwerk einer App:

• Redirects und Rewrites, optional auf einen Host begrenzt.
• Response-Header und CORS, mit Preflight-Requests, die direkt am Edge beantwortet werden.
• Eigene Fehler- und Wartungsseiten.
• Pfad-Routing, um eine App unter einem Pfad einer anderen zu bedienen.
• Eigene TLS-Zertifikate, beim Upload validiert und verschlüsselt gespeichert.
• Domain-Verifizierung über einen TXT-Eintrag, bevor Railyard eine Domain routet oder ein Zertifikat ausstellt, und Wildcard-Domains auf einem einzigen Zertifikat.
• Rate-Limits und Länder-Blocking (Beta).

Siehe Edge-Regeln und Domains.

• Canary-Deploys schicken einen Teil des Traffics an ein neues Release, in einem Schritt oder mehreren (zum Beispiel 5 %, 25 %, dann 50 %). Die Deploy-Seite vergleicht Fehlerrate und Latenz mit dem aktuellen Release, und Railyard kann selbstständig befördern oder zurückrollen.
• Deploy-Fenster und geplante Deploys. Pushes außerhalb des Fensters einer App warten, bis es sich öffnet.
• Deploy-Notizen bei manuellen Deploys und Rollbacks, und Rollbacks, die die Variablen wiederherstellen, mit denen ein Release lief.
• Apps über mehrere Server verteilt, mit health-geprüftem Load Balancing und Draining beim Entfernen.
• Automatisches Failover deployt eine App neu auf einem anderen Server, bevorzugt in einer anderen Region, wenn ihr Server nicht mehr antwortet, befördert den Datenbank-Standby und aktualisiert DNS.
• Privates Netzwerk über Server hinweg über ein verschlüsseltes WireGuard-Mesh.

Siehe Canary-Deploys und Deploy-Fenster und Skalierung und Failover.

• Die CLI ist ein einzelnes Binary für macOS und Linux, installierbar mit Homebrew oder einem Einzeiler. railyard login meldet dich mit einem im Dashboard bestätigten Code an, und railyard upgrade aktualisiert sie an Ort und Stelle.
• git push railyard main deployt genau diesen Commit und streamt das Log zurück in dein Terminal, ganz ohne GitHub. Pushes sind standardmäßig strikt: Ein fehlgeschlagener Build weist den Push zurück.
• railyard tunnel leitet einen lokalen Port zu einer App oder ihrer Datenbank weiter, ohne einen Port zu öffnen, und railyard deploy --local baut mit deinem eigenen Docker.
• Ein Terraform-Provider für Apps, Variablen und Domains.
• Image-Apps folgen ihrem Tag und deployen neu, sobald Docker Hub, GHCR, Quay oder eine private Registry einen neuen Digest veröffentlicht.

Siehe CLI und Terraform.

• Datenbank-Server halten nur Daten: kein Proxy, keine Builds, und Ports nur für die App-Server offen, die sie nutzen. Bestehende Apps können ihre Daten umziehen, mit automatischem Fallback, falls die Kopie fehlschlägt.
• Standbys, die vom Primärserver streamen und sich von der Seite jedes der beiden Server befördern lassen.
• Point-in-Time-Recovery auf jede Sekunde der letzten sieben Tage, aus WAL, das in deinem Backup-Store archiviert ist. Neue Datenbank-Server laufen auf Postgres 17.
• PgBouncer pro Server, wobei DATABASE_DIRECT_URL für Migrationen erhalten bleibt.
• Postgres-Major-Upgrades (Beta) mit Kompatibilitätscheck, vorherigem Backup und sieben Tagen Rollback-Zeit.
• Datenbank-Forks für Staging und Previews, mit optionalem Masking-Script, das läuft, bevor sich irgendjemand verbinden kann.
• Konsolen, Export und Import für jedes Add-on, ein Datei-Browser für Objektspeicher, und die Option, den Objektspeicher im eigenen AWS-Account zu behalten.

Siehe Datenbank-Server.

• Snapshots auf DigitalOcean, Hetzner, Vultr und AWS, automatisch vor jedem Resize erstellt.
• OS-Updates mit ausstehenden und sicherheitsrelevanten Zählern, End-of-Life-Warnungen, Installation mit einem Klick und optionalen nächtlichen Sicherheitsupdates.
• ActiveProtect sperrt IPs, die nach Pfaden wie /.env oder /wp-login.php suchen, und fail2ban stoppt SSH-Brute-Force. Server wechseln auf reines Key-SSH, sobald ein Key installiert ist.
• Verschlüsselter Datenbankspeicher in einem LUKS-Volume, und verschlüsselte Disks auf neuen AWS-Servern.
• Eine Web Application Firewall (OWASP Core Rule Set) pro App im Detect- oder Block-Modus, plus optionale gehärtete Isolation und Read-only-Dateisysteme für Container.
• Secret-Erkennung warnt, wenn ein Repository Zugangsdaten wie .env-Dateien oder private Keys committet.

Siehe Server-Wartung.

• Der Canvas ist eine Live-Karte eines Projekts: seine Services, Datenbanken und die Verbindungen dazwischen. Wechsle Umgebungen, forke ein Projekt, und sieh, welchen Service jedes Teammitglied gerade offen hat. Services erreichen sich über <app>.railyard.internal und referenzieren die Variablen des anderen mit ${{service.VAR}}.
• Statische Websites und Functions lassen sich direkt aus dem Canvas erstellen.
• Templates. Rund 200 Open-Source-Apps stehen in einem öffentlichen Katalog, und jedes Projekt lässt sich als Template veröffentlichen. Secrets werden nie veröffentlicht; sie werden beim Deploy abgefragt oder generiert.
• Deploy-to-Railyard-Button für READMEs, der ein vorausgefülltes Setup auf dem eigenen Server des Besuchers öffnet.
• TCP-Proxy, um von außen auf eine Datenbank zuzugreifen, im jeweiligen Panel ein- und ausschaltbar.

Siehe Der Canvas und Deploy-Button.

• Sleep nach der Leerlaufzeit, die du wählst, und Aufwachen beim nächsten Request. Staging- und Preview-Apps schlafen standardmäßig nach 30 Leerlaufminuten ein, Wachzeiten halten eine App nur zu den von dir gewählten Zeiten wach, und reine Worker-Apps wachen nach Zeitplan auf, um ihre Queues zu leeren.
• Autoscaling der Web-Replicas zwischen einer Unter- und einer Obergrenze, nach p95-Latenz oder CPU, mit geplanten Fenstern, die vor einem bekannten Peak zusätzliche Kapazität bereitstellen.
• Import aus Heroku, Render, Fly.io und Railway mit einem API-Token: Prozesse, Variablen, Datenbanken mit ihren Daten und Domains. Die Importer für Heroku, Render und Fly.io sind in Beta.
• Kosten liest deine echte Cloud-Rechnung, findet ungenutzte Server, Disks und IPs, und warnt bei 50 %, 80 % und 100 % eines Monatsbudgets. Ein optionales Hard-Cap schickt Nicht-Produktions-Apps schlafen und blockiert neue Server.
• Öffentliche Statusseiten mit 90-Tage-Uptime.

Siehe Kosten und Einsparungen und Import von einer anderen Plattform.

Rails-Apps werden bei der Erstellung erkannt. Worker werden im Repository gefunden, Assets bauen mit Propshaft, Importmap, jsbundling oder cssbundling, Active Storage bekommt ein persistentes Volume, und jede Datenbank in database.yml wird angelegt, sodass Solid Queue, Solid Cache und Solid Cable auf Rails 8 ohne Setup funktionieren.

Laravel-Apps mit laravel/octane laufen unter Octane auf FrankenPHP, und Apps mit laravel/reverb bekommen einen Reverb-Worker. Symfony und WordPress bauen ebenfalls ohne Dockerfile.

Siehe Rails und Laravel.

• Single Sign-On über OpenID Connect oder SAML 2.0, mit Google Workspace, Okta, Microsoft Entra, OneLogin und anderen. Domains werden über einen DNS-Eintrag verifiziert, neue Mitglieder treten bei der ersten Anmeldung mit der von dir gewählten Rolle bei, und SSO lässt sich für jeden auf deiner Domain erzwingen.
• SCIM 2.0 fügt Mitglieder aus deinem Identity-Provider hinzu und entfernt sie wieder.
• Sicherheitsscore von 100 Punkten aus zehn Checks, darunter Zwei-Faktor-Abdeckung, ausstehende OS-Patches, offene Ports, ablaufende Zertifikate und unverifizierte Backups. Jeder Check verlinkt direkt zur Lösung.
• Team-SSH-Keys, auf jedem Server installiert, den das Team betreibt, und innerhalb einer Minute entfernt, wenn ein Key oder ein Mitglied verschwindet.
• MCP-Server für KI-Agenten. Claude Code, Cursor und andere MCP-Clients nutzen dieselben API-Tokens wie die CLI. Destruktive Aktionen werden zu Anfragen, die ein Admin erst freigeben muss.
• Konto-Einstellungen: E-Mail und Passwort ändern, deine Daten als JSON exportieren oder dein Konto löschen.

Siehe Teams und SSO und MCP.

• Build-Server. Gib einem Server die Builder-Rolle, und er übernimmt das Kompilieren, sodass ein schwerer Build nie mit dem Live-Traffic auf deinen App-Servern konkurriert.
• Schnellere Rebuilds aus einem geteilten Build-Cache, und ein Speicher-Limit, damit ein großer Build sauber fehlschlägt statt den Server zu überlasten.
• Builds erholen sich von typischen Fehlern: veraltete Base-Images, ältere Webpack-Builds, Node ohne Speicher, Python-Packaging-Sonderfälle und PHP-Versionskonflikte. Schlägt ein Dockerfile trotzdem fehl, versucht Railyard es erneut mit Railpack und den in deinem Code fixierten Versionen.
• Multi-Service-Repositories. Eine Compose-Datei oder ein Repository mit mehreren Dockerfiles bietet an, alle Services auf einmal zu erstellen, inklusive der benötigten Datenstores.

• Metrik-Alarme auf p95-Latenz, 5xx-Rate, Arbeitsspeicher oder CPU, jede Minute geprüft, mit einer Folgemeldung, wenn sich die Lage erholt.
• Access-Logs: Jeder Request über den Proxy wird mit Methode, Pfad, Status, Dauer und Client geloggt und ist zusammen mit den Logs deiner App durchsuchbar.
• OpenTelemetry: Gib einer App einen OTLP-Endpunkt, und Railyard setzt die Standard-OTEL_*-Variablen und sendet seine eigenen CPU-, Speicher- und Request-Metriken an denselben Ort.
• Job-Queue-Ansicht (Beta) für Sidekiq, Solid Queue, GoodJob, Resque und Delayed Job, mit Retry, Discard und einem Backlog-Alarm.
• Log-Aufbewahrung pro Team, mit Suche über jeden Zeitraum und Download als Plaintext.

Siehe Logs, Metriken und Alarme.

• Ein Deploy ist fertig, wenn Nutzer ihn erreichen können, nicht wenn der Container startet. Railyard prüft die App über ihre echte HTTPS-URL, bevor der Traffic wechselt, und ein reiner Redirect gilt nicht mehr als gesunde App.
• Crash-Loops pausieren. Ein Prozess, der zehn Minuten lang immer wieder abstürzt, wird gestoppt statt endlos neu gestartet, und die App-Seite zeigt, warum er abgestürzt ist. Restart startet ihn wieder.
• Live-Fortschritt bei länger laufenden Aktionen. Server erstellen, Backups, Restores, Imports und Resizes zeigen ihre Schritte, die letzte Ausgabe und die verbleibende Zeit, und laufen weiter, auch wenn du die Seite verlässt.

Repositories ohne Dockerfile bauen jetzt automatisch mit Cloud Native Buildpacks, mit vorgebauten Runtime-Layern statt einer Sprache, die aus dem Quellcode kompiliert wird. Dein Repository wird genauso gelesen wie von Heroku, daher braucht eine umziehende App meist keine Änderungen.

Ein Procfile legt die Prozesstypen und das Release-Command fest. Web- und Worker-Prozesse starten daraus, und der Eintrag release: läuft, bevor die neue Version den Traffic übernimmt.

Siehe Build-Methoden.

• GitHub verbinden, indem du die Railyard-GitHub-App einmal installierst und dann Repositories aus einer Liste auswählst. Private Repositories werden mit kurzlebigen Tokens geklont, Pushes deployen, und Commits bekommen einen Status-Check.
• GitLab verbinden, auf gitlab.com oder selbst gehostet, mit einem Access-Token unter Team → Git-Provider.
• Preview-Umgebungen für jeden Pull Request und Merge Request, die beim Schließen entfernt werden. Staging-Umgebungen lassen sich zu Produktion befördern.
• Jeder fehlgeschlagene Deploy erklärt sich selbst: die wahrscheinliche Ursache, die Lösung und die Logzeile, die es zeigt — auf der Deploy-Seite, im Dashboard und im Canvas.

Siehe GitHub verbinden und Umgebungen und Previews.

• Teams mit den Rollen Owner, Admin, Developer und Viewer, und Mitglieder, die auf bestimmte Apps beschränkt werden können.
• Zwei-Faktor-Anmeldung mit jeder Authenticator-App, plus Backup-Codes.
• Eine REST-API mit team-gebundenen Tokens, und ein Kommandozeilen-Client, der darauf aufbaut.
• Benachrichtigungen für Deploys, offline Server und Crash-Loops, gesendet an Slack, einen Webhook oder per E-Mail.
• Deploy-Freigaben: Produktions-Deploys können darauf warten, dass ein Admin sie freigibt.
• Aktivitätslog über jeden Deploy, jede Konfigurationsänderung und jede Server-Aktion.

• Erstelle einen Server bei DigitalOcean, Hetzner, Vultr, AWS oder OVHcloud direkt im Dashboard mit deinem eigenen API-Token, oder verbinde jeden beliebigen Linux-Server per SSH. Railyard übernimmt das restliche Setup, konfiguriert die Firewall und hält den Server aktuell.
• Jede App bekommt beim Deploy sofort einen Hostnamen und ein TLS-Zertifikat. Füge eigene Domains hinzu, direkt bedient oder auf die Primärdomain umgeleitet, mit Zertifikatsstatus im Tab Domains.
• Geplante Jobs mit Ausführungsverlauf und Sofort-ausführen.
• Server-Metriken mit CPU-, Arbeitsspeicher- und Festplatten-Charts, und Alarme, wenn eine Festplatte voll läuft oder die Auslastung dauerhaft hoch bleibt.
• Wartungsmodus pro App.

Siehe Einen Server hinzufügen.

Füge einer App einen Datenstore hinzu, und Railyard betreibt ihn auf demselben Server, erstellt Zugangsdaten nur für diese App und setzt die Verbindungsvariablen beim nächsten Deploy.

• Postgres (mit pgvector), MySQL, Redis, MongoDB, Elasticsearch, Memcached, RabbitMQ, InfluxDB und S3-kompatibler Objektspeicher.
• Backups nach einem Zeitplan mit selbst gewählter Aufbewahrung, Wiederherstellung mit einem Klick, und ein Verifizierer, der jedes Backup in eine Scratch-Datenbank zurückspielt, um zu beweisen, dass es funktioniert.
• Persistente Volumes für Apps, die auf die Festplatte schreiben, mit eigenen Backups.

Siehe Datenbanken und Backups.

Railyard deployt ein Git-Repository auf einen Server, der dir gehört: Es klont den Code, baut ihn und streamt das Build-Log live in deinen Browser.

• Releases ohne Downtime. Die neue Version startet neben der alten und übernimmt den Traffic erst, wenn sie einen Readiness-Check besteht. Schlägt der Check fehl, bedient die alte Version weiter.
• Web- und Worker-Prozesse, jeweils mit eigenem Befehl und eigener Replica-Anzahl, plus ein Release-Command, das vor dem Traffic-Wechsel läuft.
• Umgebungsvariablen, verschlüsselt gespeichert und einzeln editierbar oder als .env-Block einfügbar.
• Rollback auf jedes frühere Release mit einem Klick.
• Private Quellen: tokenauthentifizierte Clones, Submodule, Build-Argumente, Build-Secrets und vorgebaute Images aus einer privaten Registry.