← Tous les guides de migration
Depuis ailleurs
Fly, DigitalOcean App Platform, Coolify, Dokku, un VPS configuré à la main. Si ça construit à partir d'un Dockerfile, de buildpacks ou d'un Procfile, ça se déplace.
La migration a toujours la même forme
Railyard n’a pas besoin d’un adaptateur spécial pour votre hébergeur actuel. Si votre application se construit à partir d’un Dockerfile, de Cloud Native Buildpacks, de Nixpacks, ou d’un Procfile, et qu’elle communique avec Postgres, MySQL ou Redis, elle se déplace.
Ce qui vous suit
- Votre dépôt et sa définition de build, inchangés.
- Vos types de processus :
web,worker,release, peu importe ce que vous exécutez. - Vos variables d’environnement.
- Vos bases de données, comme modules complémentaires gérés avec chaînes de connexion injectées.
- Vos domaines personnalisés, avec TLS automatique.
La migration
- Pointez Railyard vers un serveur : un serveur que vous avez déjà, rattaché en SSH, ou un nouveau serveur provisionné dans votre compte cloud.
- Ajoutez votre dépôt et choisissez la méthode de build qui correspond à la façon dont il se construit aujourd’hui.
- Apportez votre configuration et ajoutez les bases de données attendues par votre application.
- Déployez vers une URL temporaire et mettez l’application à l’épreuve.
- Déplacez vos données avec une sauvegarde standard, restaurée dans le module complémentaire géré.
- Basculez le DNS. Votre hébergeur actuel continue de répondre jusqu’au changement de l’enregistrement. Il n’y a aucune période où rien n’est en ligne. Ensuite, arrêtez l’ancien déploiement.
La seule règle qui rend ça sûr
Ne supprimez jamais l’ancien système avant que le DNS n’ait basculé et que vous ayez vu du vrai trafic arriver sur Railyard. Gardez l’ancienne plateforme active une semaine. Puis annulez-la.