Migrer depuis Railway

Migrez les services Railway avec leur base de données et leurs variables.

Un projet Railway est un ensemble de services reliés par des références de variables. Sur Nodion, un service doté de son propre code devient une application, les workers issus du même code deviennent des processus supplémentaires de cette app, et les bases de données deviennent des bases de données managées que vous rattachez à l'app. Nodion ne lit ni railway.json ni railway.toml ; Railway met également fin à Config as Code (arrêt définitif le 1er décembre 2026). Vous transférez donc les réglages à la main.

Correspondances entre Railway et Nodion

1. Créez le projet et les bases de données

Créez un projet et, dans ce projet, les bases de données qu'utilise votre projet Railway, dans la région où les apps doivent tourner. Pour Postgres, choisissez une version au moins aussi récente que sur Railway. À la place de Redis, Nodion propose Valkey, rattaché lui aussi en tant que REDIS_URL. Un Valkey vide ne suffit que pour des caches ou des files d'attente que vous laissez se vider au préalable ; si vous avez besoin des clés de Redis, migrez-les avant de supprimer le projet Railway. Plus d'informations dans Bases de données.

2. Copiez la base de données

Les bases de données Railway sont privées par défaut. Pour créer le dump, deux méthodes permettent d'y accéder : soit vous activez l'accès public sous Settings, Networking ; Railway crée alors un TCP proxy et définit DATABASE_PUBLIC_URL (documentation Railway), et facture le trafic qui passe par le proxy comme trafic sortant (egress). Soit vous gardez la base privée et ouvrez un tunnel avec la Railway CLI, après avoir lié le projet avec railway link. Les sauvegardes de volumes intégrées à Railway ne peuvent être restaurées que dans le même projet ; une migration nécessite donc pg_dump.

Arrêtez les écritures de vos services, puis créez le dump comme l'indique le guide de sauvegarde de Railway. Via l'accès public, utilisez la valeur de DATABASE_PUBLIC_URL issue des variables du service de base de données :

bashpg_dump "postgresql://postgres:PASSWORD@PROXY_HOST:PROXY_PORT/railway" \
  --format=custom --no-owner --file=railway.dump

Via le tunnel, liez d'abord le projet avec railway link, puis ouvrez le tunnel et, dans un second terminal, créez le dump sur localhost avec le port qu'affiche la CLI :

bashrailway link
railway connect postgres --tunnel-only

# second terminal
pg_dump "postgresql://postgres:PASSWORD@localhost:TUNNEL_PORT/railway" \
  --format=custom --no-owner --file=railway.dump

Dans Nodion, ouvrez l'onglet Overview de la base de données et cliquez sur Enable public access. Dès que l'endpoint n'affiche plus Provisioning, copiez l'URL de connexion (toujours en TLS) et ajoutez votre propre IP sous Allowed sources. Restaurez ensuite :

bashpg_restore --verbose --no-owner --no-acl \
  --dbname "postgresql://nodion:PASSWORD@HOST:PORT/DATABASE?sslmode=require" \
  railway.dump

Utilisez un pg_restore au moins aussi récent que le plus récent des deux serveurs. Vérifiez le nombre de lignes dans l'onglet Browse, puis désactivez à nouveau l'accès public, sur Railway également.

3. Créez l'application et ses processus

Créez une application par service de code, à partir de son dépôt Git. Si Railway faisait le build avec Railpack ou Nixpacks, utilisez la stratégie Buildpacks (Buildpacks) ; s'il trouvait un Dockerfile, utilisez la stratégie Dockerfile. Contrairement à Railway, Nodion ne choisit pas la stratégie à votre place : c'est vous qui la définissez.

Railway injecte PORT pour vos services. Nodion définit PORT uniquement pour le processus web des apps buildpack ; sur les apps Dockerfile, l'app écoute sur le port du processus web (sinon sur celui de l'EXPOSE de l'image, sinon sur 8080).

Si un second service utilisait le même dépôt avec une autre commande de démarrage, un worker par exemple, ajoutez-le sous Processes, New process comme processus supplémentaire de la même app et saisissez-y la commande de démarrage. Déplacez une commande exécutée avant le déploiement vers une ligne release: du Procfile (buildpacks) ou vers la commande de release de l'app (Settings, dans la carte Preview environments, où le champ apparaît une fois les previews activées, ou release_command via l'API). Elle s'exécute une fois par déploiement, avant web ; si elle échoue, la release précédente reste en ligne.

4. Transférez les variables

Affichez les variables d'un service sous forme de lignes KEY=value (Railway CLI) :

bashrailway variable list --kv > railway.env

Collez les lignes dans Environment, Add many. La Railway CLI n'affiche pas les sealed variables (documentation Railway) ; définissez-les à la main, en tant que secrets, avec nodion env set KEY=value --secret. Vérifiez les valeurs contenant des guillemets, et définissez les valeurs sur plusieurs lignes via la CLI ou l'API.

Nodion n'a pas de références comme ${{shared.KEY}} ou ${{otherService.KEY}}. Vérifiez chaque variable importée : elle doit contenir la valeur réelle, et non le texte de la référence. Là où une référence pointait vers un autre service, renseignez à la place le nom d'hôte interne de ce service sur Nodion (<app>.app.internal), ou rattachez la base de données.

Supprimez ensuite les variables qui pointent vers une base de données Railway (DATABASE_URL, REDIS_URL) : une variable que vous définissez vous-même remplace la valeur d'une base de données rattachée. Rattachez les bases de données avec Attach database. Au sein de Nodion, la connexion passe sans TLS (sslmode=disable) ; si votre code force SSL, désactivez-le pour cette URL.

5. Transférez les tâches cron

Sur Railway, une tâche cron est un service à part entière qui s'exécute puis se termine (documentation Railway). Sur Nodion, vous l'ajoutez dans l'onglet Cron de l'app dont elle utilise le code : une planification à cinq champs en UTC, la commande, un délai d'expiration de 30 minutes maximum, jusqu'à 8 tâches par app. Elle s'exécute avec la release active et les variables d'environnement de l'app.

6. Déployez, transférez le domaine, arrêtez Railway

Déployez et vérifiez l'onglet Logs. Ajoutez ensuite le domaine dans l'onglet Domains et créez les deux enregistrements qu'affiche Nodion : TXT _nodion-challenge.your-domain et un CNAME (un ALIAS à l'apex) vers le nom d'hôte par défaut de l'app. Le certificat est émis dès que le CNAME pointe vers Nodion ; comptez quelques minutes sans certificat valide et baissez le TTL au préalable. Quand tout fonctionne, supprimez le projet Railway ; selon Railway, cette suppression est définitive.

bashrailway delete --project my-project --yes

Ce qui fonctionne différemment

• Il n'y a pas d'environnements comme production et staging au sein d'un même projet ; utilisez des apps ou des projets séparés.
• Il n'y a ni variables partagées ni références ; les valeurs de base de données proviennent du rattachement de la base.
• Les tâches cron s'exécutent sur une app existante, et non comme un service à part entière.
• La CLI récupère les logs mais ne peut pas les suivre en continu ; pour les voir en direct, utilisez l'onglet Logs.

Pour aller plus loin

Nodion comparé à Railway, Tarifs, Applications et Bases de données.