Von Netlify kommend
Netlify ist gebaut für statische Seiten und JAMstack-Frontends auf Netlifys eigener Infrastruktur. Wenn deine App ein echtes Backend braucht, so läuft es auf einem Server, den du besitzt.
Warum Teams Netlify verlassen
Netlify ist exzellent für eine statische Seite oder ein JAMstack-Frontend mit Edge-Funktionen. Die Reibung zeigt sich in dem Moment, wenn deine App ein echtes Backend braucht: einen Worker, einen lang laufenden Job, einen WebSocket-Server, oder alles, was nicht in eine kurzlebige Funktion auf Netlifys Infrastruktur passt.
Railyard betreibt deine App als dauerhaften Prozess auf einem Server, den du besitzt, zusammen mit dem verwalteten Postgres, MySQL oder Redis, das sie braucht.
Was mitkommt
- Dein Repo, gebaut aus einem Dockerfile, Buildpacks, oder einem Procfile.
- Deine Umgebungsvariablen und Secrets.
- Netlifys Deploy-Previews mappen auf Railyards Preview-Umgebungen pro Pull Request.
- Ein statisches Frontend kann auf Netlify bleiben; das Backend zieht zu Railyard um, hinter derselben Domain.
Der Umzug
- Einen Server anbinden: einen bestehenden, oder einen neuen, den Railyard in deinem Cloud-Account provisioniert.
- Dein Repo hinzufügen und Railyard dein Framework erkennen lassen, oder auf dein Dockerfile zeigen.
- Deine Config mitbringen und die Datastores anhängen, die deine App erwartet.
- Deployen auf eine temporäre URL. Deinen Release-Task laufen lassen und verifizieren.
- DNS umziehen für die Backend-Route oder Subdomain. Keine Downtime.
Was anders ist
Ein echter Server für die Teile deiner App, die einen brauchen, mit HTTPS, Zero-Downtime-Releases und verwalteten Datenbanken, zu einem flachen Preis pro Team statt Abrechnung pro Invocation.