Billets sur la construction d'une plateforme de déploiement.
Des mécanismes qu'il fallait réussir, des décisions qu'il fallait défendre, et des migrations que nous avons menées plus d'une fois.
Une application plus Postgres : ce que ça coûte vraiment, plateforme par plateforme
Les prix publiés pour faire tourner une petite application avec une base de données, comparés directement — incluant ce que vous louez réellement contre ce que vous louez plus une marge.
Laisser un agent IA déployer votre application, sans risque
Un serveur MCP à portée limitée pour Claude Code, Cursor et tout autre client MCP : ce qu'il peut faire seul, ce qu'il ne peut pas, et pourquoi les actions destructives attendent une intervention humaine.
Basculement automatique de Postgres, en auto-hébergement
À quoi ressemble vraiment une promotion de serveur de secours Postgres en direct sur vos propres serveurs : la fenêtre de détection de 3 minutes, ce qui est copié, ce qui ne l'est pas, et la comparaison avec une base de données gérée.
Plausible en auto-hébergement, en une seule commande
On n'avait aucune idée de qui lisait vraiment railyard.run. Voici la stack Plausible en un clic qu'on a lancée sur notre propre plateforme pour régler ça, et ce que ça a vraiment demandé.
Ce qui se passe quand votre application construite par IA atteint la production
Un agent peut écrire une application fonctionnelle en un après-midi. Il ne sait pas que vos secrets ne devraient pas rester en texte clair, ni qu'un jeton de déploiement ne devrait pas pouvoir tout supprimer. C'est à la plateforme en dessous de le savoir à sa place.
Déployer une application Next.js sans compte Vercel
Next.js se détecte et se construit lui-même sur Railyard de la même façon que partout ailleurs — la différence est que le serveur en dessous est le vôtre, pas une facture par requête.
Des déploiements canary qui surveillent vraiment le taux d'erreur, pas juste une minuterie
Envoyez une nouvelle version à 5 % du trafic, surveillez-la contre le reste de l'application, et laissez-la se retirer toute seule si le taux de 5xx grimpe — sur des serveurs à vous, pas le bouton canary d'une plateforme gérée.
La chronologie du PaaS auto-hébergé, et d'où vient vraiment l'idée
Cloud 66 a prouvé « ne jamais héberger l'application du client » en 2012. Voici la vraie lignée de Heroku à Fly, Render, Railway et Coolify — et pourquoi l'idée continue d'être reconstruite plutôt que de se stabiliser sur un seul gagnant.
Une page de statut qui n'est pas un abonnement à 29 $/mois
Des barres de disponibilité sur 90 jours, des incidents qui s'ouvrent et se ferment tout seuls, un flux JSON pour vos propres outils — construits à partir des mêmes vérifications de disponibilité que la plateforme fait déjà tourner, pas un produit séparé à payer.
Déployer Phoenix quand votre file de tâches est déjà dans la release
Oban tourne dans le même arbre de supervision OTP que l'endpoint web — aucun deuxième processus de worker à déclarer juste pour faire tourner des tâches de fond.
Un WAF et une limite de débit sans fournisseur d'edge séparé
Filtrage OWASP Core Rule Set, limites de débit par chemin, blocage par pays — configurés sur l'application, appliqués avant que la requête ne l'atteigne. Voici exactement ce qui est en direct aujourd'hui et ce qui est encore en déploiement.
Déployer Laravel sans écrire à la main une config de worker de file
APP_KEY, migrations, Horizon, Reverb, Octane — Railyard lit ce qui est déjà dans composer.json et .env.example plutôt que de vous demander de le déclarer deux fois.
Une IP sortante stable, sans facture de passerelle NAT
Mettre l'adresse de votre serveur sur la liste blanche d'une API tierce veut habituellement dire monter une passerelle NAT sur une plateforme multi-locataire. Sur un serveur que vous possédez, l'IP n'a jamais été partagée au départ.
Déployer un service Go : le build qui n'a pas besoin de runtime
Un binaire Go n'a pas besoin d'un interpréteur récupéré, d'une version de runtime résolue, ou de quoi que ce soit installé au moment du déploiement — ce qui en fait une des choses les plus simples à construire correctement sur un serveur de build partagé.
Déployer Django sans écrire un Procfile à la main
collectstatic, gunicorn, migrations, Celery — Railyard détecte ce qui est déjà dans requirements.txt plutôt que de vous demander de déclarer la même information deux fois.
Faire tourner votre propre interface façon ChatGPT, en auto-hébergement
LibreChat se connecte à n'importe quel fournisseur de modèle pour lequel vous lui donnez des clés, avec vos conversations dans une base de données que vous contrôlez. Deux vrais pièges rencontrés en le vérifiant, et comment le gabarit les évite pour vous.
Déployer Spring Boot : pourquoi un Dockerfile est la bonne réponse, pas une solution de repli
Les commandes de build et d'exécution JVM varient trop selon l'organisation du projet pour être devinées en toute sécurité — c'est exactement pourquoi un Dockerfile est la façon délibérée et correcte de déployer une application Spring Boot, pas un contournement d'un support manquant.
Déployer Flask : un micro-framework a besoin d'une micro-configuration, pas d'aucune
Flask ne suppose pas un outil de migration ou une file de tâches comme le fait Django — ce qui veut dire qu'un déploiement Flask est honnête sur ce qui est réellement là plutôt que de deviner une convention qui n'existe pas.
Faire tourner votre propre instance Mastodon, vérifiée de bout en bout
Construite directement depuis le propre Dockerfile de Mastodon, Postgres et Redis câblés automatiquement, secrets de chiffrement générés correctement dès le départ — pas un fork simplifié de la vraie chose.
Faire tourner Laravel sur votre propre droplet DigitalOcean, sans Forge
Forge configure un droplet DigitalOcean pour vous, pour des frais mensuels, en plus du coût du droplet lui-même. Voici ce qui doit réellement se passer sur ce droplet — et comment l'obtenir sans les frais supplémentaires.
Un bouton de déploiement pour votre README, qui mène vers des serveurs que les gens possèdent
Le motif du badge de déploiement en un clic, mais qui atterrit sur le propre compte DigitalOcean ou Hetzner du visiteur plutôt que sur la facturation au compteur d'une plateforme gérée.
Une référence de service qui ne casse jamais, même avant d'activer le réseau privé
<name>.railyard.internal se résout différemment selon où les deux applications tournent réellement — même réseau de conteneur, HTTPS public, ou un maillage WireGuard multi-fournisseurs — sans que l'application sache jamais quel cas s'applique.
Pourquoi un déploiement échoue vraiment, raison par raison
Un délai de build dépassé n'est pas le même problème qu'une application qui répond sur 127.0.0.1 plutôt que 0.0.0.0 — les vraies causes derrière un déploiement échoué, et la correction précise pour chacune.
railyard.yml : la configuration de votre application comme un seul fichier dans git
Récupérez la configuration actuelle d'une application comme fichier, validez-la hors ligne, réappliquez-la — exactement ce que font les trois commandes aujourd'hui, et ce qu'elles ne font pas encore.
Un environnement de prévisualisation par pull request, sur des serveurs à vous
Chaque PR reçoit sa propre copie en marche, démontée automatiquement à sa fermeture — et contrairement à la plupart des systèmes de prévisualisation, elle dort quand personne ne regarde au lieu de facturer 24 h sur 24.
Trouver le gaspillage cloud que personne ne cherche
Des disques non attachés, des répartiteurs de charge inactifs, des serveurs qui tournent à 4 % de CPU — un scan de vos vrais comptes cloud, avec une correction en un clic pour la plupart des trouvailles, pas juste un tableau de bord qui vous dit d'aller regarder vous-même.
Quand un secret doit être un fichier, pas une variable d'environnement
Un JSON de compte de service GCP ou un certificat client ne tient pas dans une paire KEY=VALUE. La plupart des écrans de variables d'environnement des PaaS n'ont pas de bonne réponse à ça — voici celle qui en a une.
SSO et un vrai journal d'audit, sans appel commercial entreprise
L'authentification unique, le provisionnement SCIM et un vrai journal d'audit ne sont pas des fonctionnalités qu'une équipe de 6 personnes devrait avoir à négocier dans un contrat pour obtenir.
Pourquoi un domaine personnalisé ne commence pas à router avant que vous ayez prouvé le posséder
Le détournement de sous-domaine est une classe de vulnérabilité réelle et bien documentée — pointer un enregistrement DNS vers une infrastructure que vous ne contrôlez pas vraiment. Voici la vérification précise qui ferme cette porte par défaut.
10 abonnements SaaS que vous pouvez remplacer par des applications auto-hébergées en un clic
De vrais projets open source, dans la même catégorie que l'outil SaaS à côté, chacun lançable depuis le catalogue de gabarits de Railyard en un clic — pas une promesse fonctionnalité par fonctionnalité, une application qui fonctionne et que vous pouvez essayer.
Connecter TablePlus ou psql à une base de données qui n'a aucun port public
Les bases de données gérées sont privées par conception — seules les applications sur le serveur peuvent les atteindre. Voici comment un client graphique sur votre ordinateur se connecte quand même, sans ouvrir la base de données à internet pour le faire.
Faire migrer une application Rails hors de Heroku sans la réécrire
Un chemin de migration concret d'une plateforme gérée vers des serveurs à vous : d'abord les buildpacks, puis un Dockerfile, les addons, la phase de release et ce qui casse vraiment.
Être alerté sur Slack avant qu'un client ne le remarque, pas après
Échecs de déploiement, boucles de plantage, un disque qui se remplit, un certificat qui expire bientôt — un seul moteur de règles, trois canaux, limité par application ou pour toute l'équipe.
L'automatisation de flux de travail sans facture par exécution
n8n fait ce que Zapier et Make font — connecter des API sans écrire de code de liaison — sauf que vous possédez le serveur et que personne ne compte combien de fois un flux a tourné ce mois-ci.
Un déploiement n'est pas terminé quand le conteneur démarre
Qu'un conteneur soit prêt et que votre application soit réellement accessible sont deux choses différentes. Railyard vérifie les deux avant qu'un déploiement ne compte comme terminé, et revient en arrière automatiquement si la nouvelle version ne passe jamais en ligne.
Où Railyard gagne vraiment contre Heroku, Railway, Render et Fly — et où ce n'est pas le cas
Un regard honnête sur la vraie grille de comparaison : quatre choses qui découlent directement du fait de posséder le serveur, et trois choses où un concurrent est égal ou en avance.
Addon de base de données ou serveur de base de données : la différence qui compte vraiment
Les deux vous donnent Postgres. Un seul des deux survit à la perte de la machine sur laquelle il tourne. Voici exactement où se situe la limite, et quand migrer.
Migrer Heroku Postgres sans fenêtre de maintenance
La base de données est la partie d'une migration Heroku qui inquiète vraiment les équipes. Voici exactement comment les données se déplacent, et pourquoi il n'y a pas de vraie fenêtre d'indisponibilité à planifier.
Une alternative à Cloud 66 qui reste discrète
Cloud 66 a prouvé le modèle du serveur à vous il y a des années. Voici la version plus légère et moins chère de la même idée, et exactement à quoi ressemble le passage de l'un à l'autre.
Ce qui casse vraiment en quittant Render
L'expérience développeur de Render est réellement bonne. Voici ce qui survit au passage vers un serveur à vous, et la poignée de choses qui ne suivent pas automatiquement.
Les douze facteurs, sur un serveur que vous possédez
L'équipe 1.0 de Heroku a écrit le manifeste des douze facteurs pour décrire ce que leur plateforme exigeait d'une application. Voici les mêmes douze facteurs, appliqués à une infrastructure que vous possédez plutôt que vous louez.
Mise à l'échelle automatique de Rails sur CPU et temps de réponse, pas au hasard
Définissez un plancher et un plafond, et laissez la charge réelle décider — plus comment préchauffer des réplicas avant un pic de trafic que vous pouvez vraiment prévoir.
Tâches cron et workers en arrière-plan sans dyno séparé
Une commande planifiée et un worker en arrière-plan sont tous les deux de simples processus de votre application existante — pas une seconde chose à déployer, à mettre à l'échelle, ou à payer séparément.
Le traçage OpenTelemetry sans toucher à votre infrastructure
Pointez votre application vers n'importe quel collecteur OTLP et les traces, métriques et logs se mettent à circuler — la plateforme définit les variables d'environnement, le SDK de votre application fait le reste.
Ce qui rend un déploiement vraiment sans interruption
Pas du discours marketing — les étapes mécaniques précises qui font qu'il n'y a jamais un moment où votre application n'a aucun conteneur en état de répondre à une requête.
Déployer Rails sans écrire de Dockerfile
La plupart des applications Rails n'ont besoin d'aucune configuration de conteneur pour se déployer. Voici ce qui choisit vraiment la méthode de build, et quand vous devez vraiment intervenir.
Déployez votre première application sur un serveur à vous.
Connectez une machine avec un hôte, un utilisateur et une clé SSH, ou laissez Railyard en créer une dans votre compte cloud. Il installe le reste et surveille sa mise en ligne.
Offre gratuite, sans carte, et 14 jours de Pro pour chaque nouvelle équipe. Prix fixe par équipe.