Depuis Vercel

Pourquoi les équipes cherchent ailleurs

Vercel est construit autour des fonctions : votre code s’exécute à la requête, pour une durée limitée, puis s’arrête. C’est la bonne forme pour un frontend et la plupart des API. C’est la mauvaise forme pour un worker en arrière-plan, un bot qui maintient une connexion persistante, un consommateur de file d’attente, une tâche cron plus longue que la limite de temps d’une fonction, ou un serveur WebSocket. Les propres guides de Vercel pour faire tourner Docker ou un processus de longue durée sur la plateforme décrivent le déplacement de cette partie du travail vers les files d’attente ou les workflows de Vercel, ce qui est un modèle de programmation différent d’un processus serveur normal.

Les bases de données fonctionnent pareil sur Vercel : il n’y a aucune base de données que Vercel exécute elle-même. Postgres, Redis et le reste viennent du Vercel Marketplace, qui relie votre projet à un fournisseur externe comme Neon ou Upstash et injecte les identifiants. Les sauvegardes, la restauration à un instant précis et la disponibilité de la base de données sont la responsabilité de ce fournisseur, pas celle de Vercel.

Railyard est un serveur Linux normal dans votre propre compte cloud. Tout ce qui s’exécute comme un processus, que ce soit le modèle de Vercel ou non, tourne là : un worker, un bot, un consommateur de file d’attente, une tâche cron de n’importe quelle durée, Postgres ou Redis avec les sauvegardes planifiées de Railyard.

Ce qui vous suit

• Le frontend reste là où il fonctionne déjà bien, y compris sur Vercel. Il s’agit ici des parties de l’application qui ont besoin d’un serveur, pas d’une migration complète.
• Votre API ou votre backend, construit à partir de son Dockerfile ou détecté depuis le dépôt.
• Les workers en arrière-plan, les consommateurs de file d’attente et les tâches cron, comme des processus de longue durée plutôt que des fonctions avec une limite de temps.
• Un Postgres, MySQL ou Redis géré, provisionné sur le serveur plutôt qu’à travers une intégration du Marketplace.

La migration

1. Rattachez un serveur : provisionné par Railyard dans votre propre compte DigitalOcean, Hetzner, Vultr ou AWS, ou un serveur que vous avez déjà.
2. Ajoutez le dépôt de la partie qui a besoin d’un vrai serveur : l’API, le worker, le bot. Railyard le construit à partir du Dockerfile ou détecte le framework.
3. Rattachez une base de données si l’application en a besoin, avec les sauvegardes planifiées incluses.
4. Pointez le frontend vers l’URL du nouveau backend, que le frontend reste sur Vercel ou déménage aussi.
5. Déployez, vérifiez les journaux, et confirmez que le processus de longue durée reste bien en marche.

Ce qui change

Un processus qui tourne en continu plutôt que d’attendre une requête, une base de données que Railyard sauvegarde lui-même, et un serveur où vous pouvez vous connecter en SSH quand quelque chose demande un coup d’œil de plus près.