Railway vs Vercel : hosting full-stack ou plateforme frontend ?

Ces deux plateformes ne résolvent pas le même problème

Voilà ce que la plupart des comparatifs ratent : Railway et Vercel ne se battent pas pour le même job. Les mettre côte à côte, c'est un peu comme comparer un couteau suisse et un couteau de chef. L'un fait plein de choses bien. L'autre fait une chose de manière brillante.

Railway est une plateforme d'hébergement généraliste. On y fait tourner des apps web, des API, des bases de données, des cron jobs, des background workers, des containers Docker. On push du code, Railway build et deploy, et on a un service qui tourne avec des logs, des métriques et des variables d'environnement. Le full stack, dans un seul endroit.

Vercel est une plateforme de deploy optimisée pour le frontend. C'est phénoménal pour servir des apps Next.js, des sites statiques et des serverless functions en edge. C'est la boîte qui construit Next.js, et ça se voit dans chaque détail de l'expérience d'hosting. Mais dès qu'on a besoin d'une base de données, d'un background job qui tourne longtemps, ou d'un service qui n'est pas un frontend, Vercel nous renvoie ailleurs.

Comprendre cette distinction dès le départ, c'est s'éviter des mois de frustration. Choisir Vercel pour une app full-stack, c'est comme choisir une voiture de sport pour un déménagement. La voiture est super. Le job ne colle pas.

Flexibilité des workloads : la vraie ligne de démarcation

Railway peut héberger à peu près tout. Le frontend Next.js, l'API Express, la base Postgres, le cache Redis, le cron job Python qui scrape des données toutes les heures, le microservice Go qui process des webhooks -- tout ça vit dans un seul projet Railway. On voit chaque pièce du stack sur un canvas unique, connectée par des variables d'environnement partagées et du networking privé.

Cette flexibilité n'est pas juste pratique. Elle change la façon dont on pense l'architecture. Sur Railway, ajouter un worker pour envoyer des emails ou un cron job pour nettoyer les vieilles données, c'est l'affaire de cinq minutes. On ajoute un service, on le pointe vers le bon répertoire dans le monorepo, et on deploy. La connection string de la base est déjà disponible parce qu'elle est partagée dans le projet.

Sur Vercel, les options sont plus limitées. On a les serverless functions (avec des limites de temps d'exécution), les edge functions (avec des limites encore plus serrées), et les assets statiques. C'est le menu. Si l'app a besoin d'une base de données persistante, on la ramène d'un provider tiers. Si on a besoin d'un background job qui tourne plus de quelques minutes, il faut une autre plateforme pour ce service. Si on veut des connexions WebSocket, on travaille contre l'architecture de Vercel plutôt qu'avec.

Pour un site marketing statique ou une app Next.js qui fetch des données depuis des API externes, les contraintes de Vercel sont invisibles. On ne les sent jamais. Pour tout ce qui a un vrai backend, ces contraintes commencent à façonner l'architecture de manières qu'on n'a pas choisies.

Lock-in framework : neutre vs opiniâtre

Railway se fiche du framework qu'on utilise. Next.js, Remix, Astro, SvelteKit, Rails, Django, FastAPI, Go, Rust -- Railway détecte le stack et le build. S'il ne détecte pas automatiquement, on écrit un Dockerfile et Railway le fait tourner. Pas de framework préféré, pas de citoyen de première classe, pas de citoyen de seconde classe. Tout le monde est traité pareil.

Vercel supporte beaucoup de frameworks, et le support est généralement bon. Mais soyons honnêtes : Vercel est une boîte Next.js. La DX pour Next.js sur Vercel est visiblement meilleure que pour tout le reste. Les nouvelles features Next.js arrivent sur Vercel en premier et marchent le mieux là-bas. La doc assume Next.js. Les exemples utilisent Next.js. Les articles de blog parlent de Next.js.

Si on utilise Next.js et qu'on compte continuer, c'est une feature. Le framework et la plateforme sont conçus ensemble. ISR, server components, middleware, optimisation d'images -- tout marche sans bricolage d'adaptateurs.

Si on n'utilise pas Next.js, ou si on pourrait vouloir changer de framework plus tard, ce couplage devient un passif. Astro sur Vercel marche bien. Remix sur Vercel marche bien. Mais "marche bien" c'est un cran en dessous de l'expérience native Next.js, et on remarque la différence dans les edge cases, la qualité de la doc et le support des features.

Railway n'a pas ce problème parce que Railway n'a pas de cheval dans la course des frameworks.

Pricing : facturation à l'usage vs prix par siège plus surprises

Le plan Hobby de Railway est à $5/mois et inclut $5 de crédits d'usage. On paie les ressources réellement consommées : temps CPU, mémoire, egress réseau et disque. Une petite app web avec une base Postgres, ça peut tourner à $5-15/mois au total. Le plan Pro à $20/mois par membre inclut $10 de crédits d'usage et débloque les fonctionnalités d'équipe, des limites plus hautes et le scaling horizontal. Des limites de dépense empêchent les mauvaises surprises.

Le tier Hobby de Vercel est gratuit pour les projets perso non commerciaux. Le plan Pro est à $20/mois par membre. C'est ce pricing par membre qui mérite attention. Une équipe de cinq personnes, c'est $100/mois en coûts de sièges avant la moindre charge d'usage. On ajoute les dépassements de bande passante, les invocations de serverless functions, l'optimisation d'images, l'analytics, et la facture grimpe vite. On a couvert cette dynamique en détail dans notre comparatif Vercel vs Netlify.

La différence structurelle compte : Railway facture les ressources consommées. Vercel facture les personnes plus les ressources consommées. Pour les fondateurs solo, le calcul est similaire. Pour les équipes qui grandissent, le modèle de Railway scale plus doucement.

Il y a aussi un coût caché avec Vercel que les gens découvrent trop tard. Comme Vercel n'héberge ni bases de données ni services backend, on finit par payer ça séparément via Neon, PlanetScale, Upstash ou autre. Railway regroupe tout sur une seule facture. Cette simplicité vaut quelque chose, surtout quand on essaie de garder son burn rate lisible.

Base de données et backend : intégré vs apportez le vôtre

C'est ici que Railway gagne clairement, et ce n'est même pas serré.

Railway donne du provisioning en un clic pour Postgres, MySQL, Redis et MongoDB. Un clic, et on a une base qui tourne avec des connection strings automatiquement injectées dans les services liés. On peut naviguer dans les tables avec le data viewer intégré, vérifier l'usage des ressources dans le dashboard, et gérer les backups sans quitter la plateforme. Pour la vitesse entre "j'ai besoin d'une base" et "mon app lit et écrit des données", Railway est parmi les meilleures plateformes disponibles.

Vercel n'héberge pas de base de données. Du tout. Si l'app a besoin de stockage de données persistant, la réponse de Vercel est d'intégrer un provider tiers via leur marketplace. Neon pour Postgres. Upstash pour Redis. Turso pour SQLite en edge. Ces intégrations marchent, et certaines sont vraiment bonnes. Mais ça veut dire un vendor de plus, un dashboard de plus, une facture de plus, et une doc de plus à apprendre.

Pour un site de contenu qui pull des données depuis un headless CMS, c'est OK. Pour un produit SaaS avec des données utilisateurs, des requêtes transactionnelles et du background processing, l'éparpillement entre vendors ajoute une vraie complexité. On se retrouve à gérer le frontend sur Vercel, la base de données sur Neon, les background jobs sur une troisième plateforme, et les cron jobs sur encore une autre. Railway garde tout ça au même endroit.

Si on veut une base de données managée indépendante de l'hosting, Supabase se marie bien avec les deux plateformes. Mais le fait que Railway ne force pas à chercher ailleurs est un avantage concret pour les builders qui veulent garder les choses simples.

Expérience développeur : les deux excellentes, des saveurs différentes

Railway et Vercel ont toutes les deux une DX remarquable, mais optimisée pour des workflows différents.

La DX de Railway est centrée sur le canvas projet. On voit le service web, la base de données, le worker et le cron job comme des noeuds connectés sur un graphe visuel. Les logs streament en temps réel. Les métriques sont inline. Les variables d'environnement se gèrent via une vraie UI avec du scoping par service et par environnement. L'ensemble ressemble à un produit, pas à un panneau de serveur. On avait noté la même force dans nos comparatifs Railway vs Render et Railway vs Fly.io.

La DX de Vercel est centrée sur le cycle de deploy. On push sur Git. Vercel build l'app automatiquement. Un deploy preview apparaît sur une URL unique en quelques secondes. L'équipe review la preview, merge la PR, et le deploy de prod part. Ce workflow est rapide, poli et profondément satisfaisant quand on itère sur un frontend. L'intégration avec Next.js donne des builds zero-config, du code splitting automatique, des pages statiques optimisées en edge, et de l'optimisation d'images qui marche toute seule.

Pour les workflows frontend-heavy, l'expérience de deploy de Vercel est difficile à battre. Pour les workflows full-stack où le backend compte autant que le frontend, la vue projet de Railway donne plus de visibilité sur tout le système.

Les deux plateformes ont de bons outils CLI, une bonne intégration Git et une bonne documentation. C'est vraiment un match nul -- juste optimisé pour des types de travail différents.

Scaling : auto-scale serverless vs contrôle par ressources

Le modèle de scaling de Vercel est serverless. Le frontend est servi depuis un CDN global. Les serverless functions scalent automatiquement selon les requêtes entrantes. On ne provisionne pas d'instances, on ne choisit pas de régions, on ne règle pas de replica counts. Pic de trafic ? Vercel gère. Le trafic retombe ? On arrête de payer la capacité inutilisée. Pour les workloads frontend avec des patterns de trafic imprévisibles, ce modèle est élégant et efficace.

Le tradeoff, c'est le contrôle. On ne peut pas faire tourner un process long-lived. On ne peut pas garder une connexion WebSocket ouverte indéfiniment. L'exécution des serverless functions a des limites de temps (10 secondes sur Hobby, 60 secondes sur Pro, jusqu'à 300 secondes sur Enterprise). Si les besoins backend dépassent ces limites, l'architecture de Vercel joue contre soi.

Le scaling de Railway est basé sur les ressources. On fixe des limites CPU et mémoire par service, et Railway fait tourner les containers dans ces bornes. On peut scaler verticalement en augmentant les limites de ressources ou horizontalement en ajoutant des replicas sur les plans Pro. La facturation à l'usage fait qu'on paie la consommation réelle, pas la capacité provisionnée.

Pour un site marketing qui prend un pic de trafic après un lancement sur Product Hunt, l'auto-scaling de Vercel est mieux adapté. Pour un backend SaaS qui a besoin de performance prévisible et de connexions persistantes, le modèle de Railway est plus approprié. Pour beaucoup de projets indés, le scaling ne sera pas le bottleneck -- on va taper dans des problèmes de produit avant des problèmes d'infrastructure.

Quand choisir Railway

• Le produit a un backend : une API, une base de données, des background workers ou des cron jobs.
• On veut tout dans une seule plateforme au lieu de jongler entre des vendors.
• On n'est pas marié à Next.js et on veut la liberté de framework.
• On préfère une facturation à l'usage liée à la consommation réelle de ressources.
• On veut du provisioning de base de données instantané sans configurer un provider séparé.
• On construit un MVP ou un side project et on veut le chemin le plus rapide vers une app full-stack qui tourne.
• On a lu le comparatif Railway vs Render et on veut la DX la plus moderne.

Quand choisir Vercel

• Le produit est une app Next.js et on veut la meilleure intégration framework-plateforme possible.
• Le backend vit ailleurs (API externes, Supabase, Firebase) et on n'a besoin que d'hosting frontend.
• On veut de l'auto-scaling serverless et une distribution edge globale sans penser à l'infrastructure.
• Les deploy previews sur chaque pull request sont critiques pour le workflow de l'équipe.
• On construit un site de contenu, un site marketing ou un site de documentation essentiellement statique.
• L'ISR, l'optimisation next/image et l'edge middleware sont importants pour le produit.
• L'équipe est assez petite pour que le pricing par siège ne fasse pas mal.

L'approche hybride : utiliser les deux

Voilà ce que le cadrage "soit l'un soit l'autre" rate : beaucoup d'équipes utilisent les deux.

On héberge le frontend Next.js sur Vercel. On héberge l'API, la base de données et les workers sur Railway. Vercel gère ce qu'il fait le mieux -- servir le frontend vite, à l'échelle mondiale, avec des deploy previews et de l'optimisation edge. Railway gère ce qu'il fait le mieux -- faire tourner les services backend, gérer les bases de données, et garder tout dans un seul projet.

Ce n'est pas un compromis. C'est sans doute le setup optimal pour une app Next.js full-stack. On récupère le polish framework-native de Vercel pour le frontend et la flexibilité opérationnelle de Railway pour tout le reste. Les deux plateformes communiquent en HTTP comme n'importe quel split frontend-backend.

Le seul inconvénient, c'est de gérer deux plateformes au lieu d'une. Si cet overhead gêne et que le backend est assez simple, Railway peut aussi héberger le frontend Next.js. On perd certaines optimisations edge de Vercel, mais on gagne en simplicité opérationnelle.

Verdict final

Railway et Vercel sont deux plateformes excellentes qui sont bonnes dans des choses très différentes.

Si on construit un produit full-stack -- quelque chose avec des utilisateurs, une base de données, une API et du background processing -- Railway est le meilleur fit. Ça gère tout le stack au même endroit, la facturation est claire, et la DX est remarquable. Pas besoin de coller ensemble trois vendors juste pour avoir un backend qui marche.

Si on construit un produit frontend-heavy sur Next.js qui parle à des services externes pour ses données, Vercel est le meilleur fit. L'intégration framework est inégalée, le workflow de deploy est beau, et le modèle de scaling serverless gère les pics de trafic sans réflexion opérationnelle.

L'erreur, c'est de les traiter comme des substituts. Ce sont des compléments. On choisit celui qui correspond à ce qu'on construit vraiment, ou on utilise les deux et on laisse chaque plateforme faire ce qu'elle fait le mieux.