Ce qui casse vraiment en quittant Render

Render n’a rien fait de mal. C’est ce qui rend cette migration différente de celle de Heroku : personne ne part parce que le produit est mauvais. On part parce que c’est l’infrastructure de Render, les régions de Render, et la facture de Render, et les trois deviennent moins confortables à mesure qu’une application grandit vraiment.

Ce qui suit proprement

L’importateur de Railyard lit un compte Render directement depuis un jeton API : dépôt et branche, variables d’environnement, commande de démarrage et domaines personnalisés suivent tels quels. Les workers en arrière-plan sur Render deviennent des processus worker ordinaires sur Railyard — même travail, hôte différent.

Si vous migrez à la main plutôt qu’avec l’importateur, les mêmes éléments se correspondent directement :

• Votre Dockerfile, si vous en avez un — le même que Render utilise déjà.
• L’intention d’un render.yaml : les définitions de services web et worker deviennent des types de processus Railyard, et un preDeployCommand devient une tâche de release qui s’exécute avant que la nouvelle version ne prenne le trafic.
• Les variables d’environnement et les groupes d’environnement, collés tels quels.
• Render Postgres et Render Key Value correspondent à des addons Postgres et Redis gérés, avec les chaînes de connexion injectées de la même façon que Render les injecte aujourd’hui.

Ce qui ne suit pas automatiquement

Deux choses demandent une étape délibérée, pas un interrupteur :

• Les valeurs des fichiers secrets. L’importateur rapporte les noms de ce que Render stockait comme fichier secret, pas le contenu — à ressaisir à la main une fois.
• Les données elles-mêmes. Une base de données migre en diffusant un pg_dump depuis le DATABASE_URL de Render directement vers le nouveau Postgres géré. Gardez l’ancienne base en marche jusqu’à ce que la nouvelle réponde correctement, puis seulement ensuite basculez le DNS.

La migration, dans l’ordre

1. Pointez Railyard vers un serveur dans votre propre compte DigitalOcean, Hetzner ou AWS — ou attachez-en un que vous gérez déjà.
2. Ajoutez le dépôt et confirmez la méthode de build que Render utilise déjà (habituellement le Dockerfile).
3. Recréez la configuration : collez les variables d’environnement, attachez Postgres/Redis pour que les chaînes de connexion se câblent automatiquement.
4. Déployez vers l’URL temporaire et exercez vraiment l’application, tâches en arrière-plan incluses, avant de toucher au DNS.
5. Faites passer les données, vérifiez-les, puis basculez le DNS. Render continue de servir tout ce temps — il n’y a aucune fenêtre où l’application est hors ligne.

Ce qui est vraiment différent ensuite

La machine est à vous. Pas de surprise d’egress au gigaoctet à la fin d’un bon mois, pas d’attente pour une région que Render n’a pas encore ajoutée, et si jamais vous décidez de quitter Railyard aussi, les conteneurs continuent de tourner sur une machine que vous possédez déjà — rien dans la sortie ne dépend de nous.

Correspondance technique complète : Migrer depuis Render, la comparaison avec Render, et Importer depuis Heroku, Render, Fly ou Railway.