Oui, il existe des solutions canadiennes à Railway. Voici ce qui change sur la facture.

Railway énumère quatre régions de déploiement, toutes sur son propre matériel (« Metal »). Aucune n’est au Canada, et la page dit seulement que d’autres pourraient s’ajouter.

Railway facture à la seconde la mémoire, le processeur, le disque et le trafic sortant que vos services consomment, en plus d’un forfait qui inclut ce même montant d’utilisation. Ceux qui quittent Railway veulent souvent l’inverse : un montant connu d’avance. Le tableau chiffre une petite appli qui tourne tout le mois.

Les gabarits de base de données de Railway couvrent PostgreSQL, MySQL, Redis et MongoDB, chacun avec une variante à haute disponibilité et un basculement automatique une fois activé. Les sauvegardes et la récupération à un instant précis (pour Postgres et MySQL) sont aussi à activer vous-même, et Railway dit ne publier aucune garantie de disponibilité.

• Canner n’offre que Postgres. Ni MySQL, ni MongoDB, ni Redis.
• Pas de haute disponibilité ni de basculement. Une base Canner tourne sur un seul serveur à Montréal. S’il vous faut une réplique de relève, Railway, DigitalOcean ou un grand nuage public conviennent mieux.
• Des sauvegardes à configurer dans chaque forfait. Chaque forfait peut planifier des sauvegardes chiffrées par base, restaurer dans une nouvelle base ou en place, et copier les sauvegardes vers jusqu’à cinq compartiments compatibles S3 qui vous appartiennent (documentation des bases).
• La récupération à un instant précis, à n’importe quel moment d’une fenêtre de 1 à 35 jours, vient avec l’instance dédiée à 9 $/mois par projet, qui ajoute aussi pgvector, PostGIS, pg_cron et la réplication logique.

Un projet Railway regroupe souvent plusieurs services : une API, une interface, un travailleur, une base. Sur Canner, un projet exécute un seul processus. Chaque service exposé au Web devient son propre projet avec sa propre adresse, et ils se parlent en HTTPS. Un travailleur qui consomme une file doit plutôt s’exécuter dans un processus web, avec une file stockée dans Postgres comme GoodJob, Solid Queue ou pg-boss (tâches en arrière-plan). Si votre architecture repose sur plusieurs services internes reliés par un Redis, Railway ou Fly.io lui conviendront mieux.

Les bases Railway sont privées par défaut. Pour en copier une, activez Public Access dans les paramètres réseau du service Postgres : Railway crée un mandataire TCP et une variable DATABASE_PUBLIC_URL. Railway précise que le trafic qui passe par ce mandataire compte comme trafic sortant; la copie elle-même est donc facturée à 0,05 $/Go.

Ensuite, la CLI Canner fait le reste depuis votre terminal : elle transfère la base sans fichier de vidage, et deploy --follow téléverse le code et affiche le journal de compilation jusqu’à ce que l’appli soit en ligne.

# 1. On Railway: Postgres service → Settings → Networking → Public Access
#    (creates a TCP proxy and a DATABASE_PUBLIC_URL variable)
# 2. On your machine:
npm install -g @canner-ca/cli
canner login
canner init --slug my-app
canner db init
canner db migrate-in --from "<DATABASE_PUBLIC_URL from Railway>"
canner deploy --follow

• Restez sur Railway s’il vous faut des bases à haute disponibilité, MySQL ou MongoDB, ou plusieurs services sur un réseau privé, et qu’un hébergement aux États-Unis ou en Europe est acceptable.
• Fly.io pour une facturation à l’utilisation comme celle de Railway, avec une région à Toronto, si un propriétaire américain vous convient.
• DigitalOcean App Platform pour des prix fixes par conteneur à Toronto, avec Postgres et Valkey dans la même ville.
• MapleDeploy pour un serveur de propriété canadienne à Toronto qui peut exécuter Redis, MySQL et MongoDB à côté de votre appli.
• Canner pour une plateforme gérée de propriété canadienne au Québec, avec une facture fixe, Postgres inclus, et des applis qui tournent en un seul processus. La page des comparatifs présente les autres.