D’où ils viennent

Railway a été fondé en 2020 par Jake Cooper et Aaron Harnly, deux développeurs frustrés par l’état de l’art du PaaS (Platform as a Service) à l’époque. Heroku, lancé en 2007, était devenu le standard — mais le produit s’était stagné depuis l’acquisition par Salesforce en 2010, et la roadmap était illisible. AWS était puissant mais demandait des compétences DevOps que les développeurs solo n’avaient pas envie d’acquérir. Render et Fly.io étaient prometteurs mais jeunes. Le marché avait besoin d’un Heroku moderne.

Railway est passé par Y Combinator W21, a levé en Series A (Tiger Global, Redpoint, 20 M USD), et a connu un boom d’utilisateurs en 2022 quand Heroku a supprimé son plan gratuit — des dizaines de milliers d’apps ont migré, et Railway était la destination la plus simple. En 2026, Railway est l’un des PaaS modernes les plus utilisés, avec un focus assumé sur l’expérience développeur et un pricing à l’usage transparent.

Ce que c’est vraiment

Railway est un PaaS (Platform as a Service) qui te permet de déployer des applications sans gérer de serveurs. Les capacités principales :

  • Services applicatifs — connecte un repo GitHub, Railway détecte le langage (Python, Node, Go, Rust, Ruby, etc.), build et déploie automatiquement
  • Databases managed — Postgres, MySQL, Redis, MongoDB provisionnés en un clic dans le même projet
  • Variables d’environnement partagées entre services
  • Domaines personnalisés avec SSL automatique
  • Logs et metrics centralisés
  • Pricing à l’usage — RAM-hours, CPU-hours, egress, storage facturés à la consommation réelle
  • Multi-région — déployer en us-west, us-east, eu-west, asia-southeast

Le workflow typique : tu crées un Project, tu ajoutes des Services dedans (ton app, une DB Postgres, un cache Redis), tu connectes Git, et chaque push déclenche un nouveau déploiement. Variables d’env partagées via Reference Variables — ${{Postgres.DATABASE_URL}} dans ton app pointe automatiquement vers la base provisionnée.

Pour démarrer vite, Railway Templates offre des stacks pré-configurées (Next.js + Postgres + Redis, Discord bot Python, n8n, etc.) que tu déploies en un clic.

Comment ça s’intègre avec Claude Code

Pour un opérateur qui ship un backend depuis Claude Code, le flux typique :

  1. Tu crées un projet Railway lié à ton repo GitHub (5 min la première fois)
  2. Tu travailles dans Claude Code comme d’habitude — l’agent écrit ton API FastAPI/Express, configure les variables d’env, ajoute les dépendances
  3. Tu push sur la branche main — Railway build, deploy, et l’URL est en ligne
  4. Pour debug — tu demandes à Claude Code de fetcher les logs Railway (via CLI railway logs) ou de checker le status

Le backend LeadLoup tourne sur Railway en 2026 — FastAPI principal, plusieurs services secondaires (bot Messenger, scraper Apify, cron jobs de monitoring), tous dans le même projet, avec Postgres et Redis provisionnés à côté.

Le truc qui change vraiment : Railway facilite les architectures multi-services sans la complexité Kubernetes. Tu peux avoir 5 services qui se parlent via variables d’env partagées, déployés dans le même projet, sans configurer un cluster.

Pour qui c’est fait

Railway est conçu pour les développeurs qui veulent ship un backend sans devenir SRE. Si tu veux du Kubernetes managé pour 50 microservices, prends GKE ou EKS. Si tu veux du Postgres + une API Python + un cron job, prends Railway.

Public idéal :

  • Développeurs solo qui shippent des side projects et MVPs
  • Indie hackers qui font tourner des bots, scrapers, jobs cron
  • Petites équipes tech (1-15 personnes) qui veulent un PaaS sans friction
  • Studios qui maintiennent plusieurs services en parallèle (un projet Railway par client par exemple)
  • Fondateurs techniques qui veulent Postgres + serveur dans un seul dashboard

Public moins adapté : les très grosses applications à très haut trafic (les coûts d’egress et de compute peuvent surprendre à l’échelle), les workloads frontend pur (Vercel ou Cloudflare Pages restent mieux), et les workflows qui demandent un accès SSH à un vrai serveur Linux (Railway abstrait ça).

Le verdict de la Taverne

Le backend de LeadLoup tourne sur Railway depuis le début. FastAPI principal, services secondaires (bot Messenger via AgentChat, scraper Apify pour Ad Library Meta, cron de monitoring), Postgres et Redis à côté — tout dans le même projet, déployé automatiquement à chaque push.

Ce qui me garde dessus :

  • La simplicité. Connecte GitHub, ajoute un service, c’est en ligne en 2 minutes. Pas de YAML Kubernetes, pas de pipeline CI custom, pas de gestion de certificats SSL.
  • Postgres + Redis dans le même projet que mon app. Variables d’env partagées via ${{Postgres.DATABASE_URL}}. C’est ce que Heroku a perdu en cours de route.
  • Pricing à l’usage transparent. Tu vois exactement ce que tu consommes (RAM-hours, CPU-hours, egress). Pas de surprises mensuelles au-delà de ce que tu as réellement utilisé.
  • Le push-to-deploy marche, vraiment. Mes commits dans Claude Code arrivent en prod 60 secondes plus tard.

Ce qui m’agace :

  • Les coûts qui montent vite à fort trafic. Egress payant ($0.10/GB hors plan), compute facturé à la seconde. Pour LeadLoup à mon échelle, c’est 20-30 USD/mois — gérable. Pour un produit à 1M req/jour, faut réévaluer.
  • Pas de région Canada en 2026. US-East fonctionne (latence ~30-50 ms depuis Montréal), mais pour des données ultra-sensibles Loi 25, il faudrait Cloudflare Workers + D1 ou self-host.
  • Pas de programme affiliate en 2026 — recommandation au mérite.

Bottom line : si tu ship un backend custom en 2026 (FastAPI, Express, jobs Python) et tu veux ne pas devenir DevOps, Railway est probablement le bon défaut. Le plan Hobby à 5 USD/mois suffit pour démarrer, le Pro à 20 USD/mois pour passer en commercial sérieux.

Au Québec

L’interface est en anglais seulement (pas de localisation FR). La facturation se fait en USD via Stripe (~38 % de change en CAD). Pas de TPS/TVQ ajoutée à la facture — Railway n’a pas de présence taxable au Canada en 2026.

Les régions disponibles incluent us-west, us-east, eu-west, asia-southeast. Pas de région Canada en 2026 — c’est un manque pour les données sensibles soumises à la Loi 25. Latence depuis Montréal/Québec vers us-east-1 (Virginie) est ~30-50 ms, acceptable pour la plupart des usages.

Conformité Loi 25 : pour les données sensibles (santé, finance, juridique), Railway peut ne pas être suffisant en 2026 — envisager Cloudflare Workers + D1 (région CA disponible) ou self-host Postgres sur un VPS canadien (OVHcloud Beauharnois, AWS ca-central-1).

L’abonnement Hobby/Pro et l’usage sont déductibles comme dépense d’exploitation pour entreprises et travailleurs autonomes au Québec — garde les factures mensuelles Stripe pour ta comptabilité.