SMF·RAILWAY
Un prompt peut-il remplacer Railway ?
Hébergement et déploiement — application hosting and backend platforms
Bordereau de suivi des pièces
Verdict
Déployer une poignée de conteneurs de confiance sur un serveur que tu contrôles — avec TLS automatique, contrôles de santé, et redémarrages progressifs — est un vrai projet de week-end par-dessus des outils qui existent déjà. Ce que tu abandonnes en prenant cette voie : l’infrastructure multi-régions gérée de Railway, les modèles de base de données en un clic, et le fait que quelqu’un d’autre porte le bipeur opérationnel quand une machine tombe à 3 heures du matin.
Pièce A — Le prompt
Reçu le31.07.2026Construis un PaaS minimal sur un seul serveur : pointe-le vers un dépôt Git ou une image de conteneur, et fais-lui construire (via un Dockerfile détecté ou fourni), faire tourner, et exposer l’appli via du HTTPS automatique sur ton propre domaine. Utilise Docker Compose pour orchestrer, et Caddy comme reverse proxy — la gestion automatique des certificats Let's Encrypt de Caddy fait l’essentiel de la partie difficile gratuitement. Construis un petit service de plan de contrôle (Go, Node, ou ton langage préféré) qui surveille les nouveaux commits ou les déclencheurs de redéploiement manuel, construit l’image, vérifie la santé du nouveau conteneur avant de router le trafic vers lui (un simple échange bleu-vert), et garde les dernières images de conteneur pour un retour arrière instantané. Stocke les variables d’environnement par appli, chiffrées au repos, injectées au démarrage du conteneur — jamais écrites dans les journaux. Diffuse les journaux de build et d’exécution vers un fichier local borné par appli, consultable via un tableau de bord web minimal. Ajoute une alerte basique au niveau de l’hôte sur le disque/la mémoire (même juste un email quand le disque dépasse 90 %). Ne construis pas d’orchestration multi-serveurs, de mise à l’échelle automatique, ni de provisionnement de base de données géré — ceci tourne explicitement sur un serveur, et cette limitation de point de défaillance unique doit figurer dans le README, pas cachée. Nécessite un serveur (un VPS à 5-6 $/mois suffit pour quelques petites applis) et un domaine qui pointe dessus ; aucun autre service externe requis.L’ouverture pré-remplit le prompt — il ne reste qu’à appuyer sur entrée.
Pièce B — Ce que tu perds
- B.1 l’infrastructure multi-régions gérée
- B.2 le provisionnement de base de données en un clic
- B.3 la mise à l’échelle automatique sous charge
- B.4 quelqu’un d’autre d’astreinte pour les incidents d’infrastructure
Alternatives existantes
Pièce C — Pourquoi certains continuent de payer : infrastructure scale, operations, and reliability
Un bouton de déploiement est facile à simuler ; être l’équipe qui se fait biper quand un data center a une mauvaise nuit, c’est le vrai produit.
Questions
Est-ce que ça peut monter en charge comme le fait Railway ?
Non — c’est délibérément une conception à un seul serveur. Si une appli a besoin de monter en charge au-delà de ce que cette machine peut gérer, la réponse honnête de ce projet, c’est de la déplacer, pas de la forcer à tenir ici.
Que se passe-t-il si le serveur tombe ?
Tout ce qui tourne dessus tombe avec lui, et il n’y a pas de basculement automatique — c’est le vrai compromis pour se passer de l’infrastructure gérée de Railway.
Est-ce que ça supporte des bases de données comme Postgres nativement ?
Tu peux déployer un conteneur Postgres de la même façon que n’importe quelle autre appli, mais il n’y a pas de base de données gérée en un clic avec sauvegardes automatiques — tu es responsable de la sauvegarder toi-même.
Combien ça coûte à faire tourner ?
Ce que coûtent ton VPS et ton domaine — souvent moins de 10 $ par mois au total pour une poignée de petites applis, contre la facturation à l’usage de Railway qui grimpe avec le trafic et l’utilisation des ressources.
Outils proches
Récépissé