Von Vercel kommend
Vercel ist exzellent für Frontends und Serverless-Funktionen. Ein Worker, ein Bot, eine Queue oder alles, was dauerhaft laufen muss, braucht eine andere Art von Host.
Warum Teams sich anderswo umsehen
Vercel ist um Funktionen herum gebaut: Dein Code läuft bei Anfrage, für eine begrenzte Zeit, dann stoppt er. Das ist die richtige Form für ein Frontend und die meisten APIs. Es ist die falsche Form für einen Background-Worker, einen Bot, der eine dauerhafte Verbindung hält, einen Queue-Consumer, einen Cron-Job, der länger läuft als das Zeitlimit einer Funktion, oder einen WebSocket-Server. Vercels eigene Guides zum Betreiben von Docker oder eines lang laufenden Prozesses auf der Plattform beschreiben, diesen Teil der Arbeit in Vercels Queues oder Workflows zu verschieben, was ein anderes Programmiermodell ist als ein normaler Server-Prozess.
Datenbanken funktionieren auf Vercel genauso: Es gibt keine Datenbank, die Vercel selbst betreibt. Postgres, Redis und der Rest kommen aus dem Vercel Marketplace, der dein Projekt mit einem separaten Provider wie Neon oder Upstash verbindet und die Credentials injiziert. Backups, Point-in-Time-Restore und die Uptime der Datenbank selbst sind Sache dieses Providers, nicht Vercels.
Railyard ist ein normaler Linux-Server in deinem eigenen Cloud-Account. Alles, was als Prozess läuft, Vercels Modell oder nicht, läuft dort: ein Worker, ein Bot, ein Queue-Consumer, ein Cron-Job beliebiger Länge, Postgres oder Redis mit Railyards eigenen geplanten Backups.
Was mitkommt
- Das Frontend bleibt, wo es schon gut funktioniert, auch auf Vercel. Hier geht es um die Teile der App, die einen Server brauchen, nicht um einen kompletten Umzug.
- Deine API oder dein Backend, gebaut aus ihrem Dockerfile oder aus dem Repo erkannt.
- Background-Worker, Queue-Consumer und Cron-Jobs, als lang laufende Prozesse statt Funktionen mit Zeitlimit.
- Ein verwaltetes Postgres, MySQL oder Redis, auf dem Server provisioniert statt über eine Marketplace-Integration.
Der Umzug
- Einen Server anbinden: von Railyard in deinem eigenen DigitalOcean-, Hetzner-, Vultr- oder AWS-Account provisioniert, oder einen, den du schon hast.
- Das Repo hinzufügen für den Teil, der einen echten Server braucht: die API, den Worker, den Bot. Railyard baut es aus dem Dockerfile oder erkennt das Framework.
- Eine Datenbank anhängen, falls die App eine braucht, mit geplanten Backups inklusive.
- Das Frontend auf die URL des neuen Backends zeigen, egal ob das Frontend auf Vercel bleibt oder mit umzieht.
- Deployen, Logs prüfen, und bestätigen, dass der lang laufende Prozess auch tatsächlich am Laufen bleibt.
Was anders ist
Ein Prozess, der dauerhaft läuft, statt auf eine Anfrage zu warten, eine Datenbank, die Railyard selbst sichert, und ein Server, auf den du per SSH kommst, wenn mal genauer hingeschaut werden muss.