Ce qui a été livré, du plus récent au plus ancien.

railyard apps:rm <app> supprime une application depuis la CLI, mais seulement avec --confirm <nom-app> correspondant au nom exact de l’application — le même modèle de confirmation tapée que le tableau de bord utilise déjà pour les actions destructrices, pour qu’un déploiement scripté ne puisse pas supprimer la mauvaise application par une faute de frappe.

Passe de vérification en direct sur des dizaines de gabarits d’applications communautaires — Immich, Affine, MediaCMS, Supabase, Dify, Appwrite, LibreChat, Seafile, Rocket.Chat, PostHog, LogChimp, Castopod, Zulip, Airbyte, Langfuse et d’autres — et correction de ce qu’un vrai déploiement a réellement révélé : variables d’environnement manquantes, mauvais ports par défaut, et quelques collisions de clé de lancement où deux gabarits partageaient le même identifiant.

Même passe, trois corrections au niveau de la plateforme qui n’étaient jamais visibles au quotidien mais rendent un serveur plus susceptible de se guérir tranquillement lui-même plutôt que d’avoir besoin d’une intervention manuelle : un serveur qui attache du stockage sur un chemin de périphérique inattendu, un surveillant de routage qui redémarrait trop facilement, et un changement DNS que ses dépendants ne reprenaient pas toujours. Parcourir le catalogue de gabarits.

N’importe qui peut maintenant s’inscrire sans invitation. Les nouvelles équipes démarrent sur l’offre Gratuit (1 serveur, 3 applications) avec 14 jours de Pro, sans carte. Pro et Team sont des prix fixes par équipe, sans facturation à l’usage; les équipes qui se sont jointes avant aujourd’hui gardent Pro gratuitement. Tarifs, Docs.

Une revue de sécurité indépendante a mené à une portée plus stricte des jetons d’API, des vérifications plus strictes sur les requêtes sortantes et les noms d’hôte, et plus d’environnements d’aperçu pour les pull requests venant de forks. Nous avons aussi corrigé plusieurs problèmes mineurs dans la création d’applications, les mises à jour de statut de déploiement et les pages publiques.

Le proxy devant chaque application gère maintenant ce que vous configureriez autrement dans Nginx, depuis Settings → Networking d’une application :

• Redirections et réécritures, limitées à un seul hôte si vous le voulez.
• En-têtes de réponse et CORS, avec les requêtes préliminaires traitées à l’edge.
• Pages d’erreur et de maintenance personnalisées.
• Routage par chemin pour servir une application sous un chemin d’une autre.
• Vos propres certificats TLS, validés au téléversement et stockés chiffrés.
• Vérification de domaine par un enregistrement TXT avant que Railyard ne route un domaine ou n’émette un certificat, et des domaines génériques (wildcard) sur un seul certificat.
• Limites de débit et blocage par pays (bêta).

Voir Règles edge et Domaines.

• Les déploiements canary envoient une part du trafic vers une nouvelle version, en une étape ou plusieurs (par exemple 5 %, 25 %, puis 50 %). La page de déploiement compare son taux d’erreur et sa latence avec la version actuelle, et Railyard peut promouvoir ou revenir en arrière de lui-même.
• Plages de déploiement et déploiements planifiés. Les push hors de la plage d’une application attendent qu’elle s’ouvre.
• Notes de déploiement sur les déploiements manuels et les retours en arrière, et des retours en arrière qui restaurent les variables avec lesquelles une version s’exécutait.
• Applications sur plusieurs serveurs, avec répartition de charge vérifiée par contrôle de santé et vidage à la suppression.
• Bascule automatique redéploie une application sur un autre serveur, de préférence dans une autre région, quand son serveur arrête de répondre, promeut la réplique de base de données et met à jour le DNS.
• Réseau privé entre serveurs sur un maillage WireGuard chiffré.

Voir Déploiements canary et plages de déploiement et Mise à l’échelle et bascule.

• La CLI est un binaire unique pour macOS et Linux, installé avec Homebrew ou un script en une ligne. railyard login connecte avec un code confirmé dans le tableau de bord, et railyard upgrade la met à jour sur place.
• git push railyard main déploie exactement ce commit et diffuse le journal dans votre terminal, sans besoin de GitHub. Les push sont stricts par défaut : un build échoué rejette le push.
• railyard tunnel redirige un port local vers une application ou sa base de données sans ouvrir de port, et railyard deploy --local construit avec votre propre Docker.
• Un fournisseur Terraform pour les applications, les variables et les domaines.
• Les applications images suivent leur tag, et redéploient quand Docker Hub, GHCR, Quay ou un registre privé publie un nouveau digest.

Voir CLI et Terraform.

• Les serveurs de base de données ne contiennent que des données : pas de proxy, pas de builds, et des ports ouverts seulement aux serveurs d’applications qui les utilisent. Les applications existantes peuvent y transférer leurs données, avec repli automatique si la copie échoue.
• Répliques qui diffusent depuis le serveur principal et peuvent être promues depuis la page de l’un ou l’autre serveur.
• Restauration à un instant précis à n’importe quelle seconde des sept derniers jours, à partir du WAL archivé dans votre entrepôt de sauvegardes. Les nouveaux serveurs de base de données exécutent Postgres 17.
• PgBouncer par serveur, avec DATABASE_DIRECT_URL conservée pour les migrations.
• Mises à niveau majeures de Postgres (bêta) avec une vérification de compatibilité, une sauvegarde d’abord et sept jours pour revenir en arrière.
• Copies de base de données pour le staging et les aperçus, avec un script de masquage optionnel qui s’exécute avant que quiconque puisse se connecter.
• Consoles, export et import pour chaque module, un gestionnaire de fichiers pour le stockage d’objets, et l’option de garder le stockage d’objets dans votre propre compte AWS.

Voir Serveurs de base de données.

• Instantanés sur DigitalOcean, Hetzner, Vultr et AWS, pris automatiquement avant chaque redimensionnement.
• Mises à jour de l’OS avec comptes des correctifs en attente et de sécurité, avertissements de fin de vie, installations en un clic et mises à jour de sécurité nocturnes optionnelles.
• ActiveProtect bannit les IP qui sondent des chemins comme /.env ou /wp-login.php, et fail2ban arrête les attaques SSH par force brute. Les serveurs basculent en SSH par clé seulement une fois qu’une clé est installée.
• Stockage de base de données chiffré dans un volume LUKS, et disques chiffrés sur les nouveaux serveurs AWS.
• Un pare-feu applicatif web (OWASP Core Rule Set) par application, en mode détection ou blocage, plus une isolation renforcée et des systèmes de fichiers en lecture seule optionnels pour les conteneurs.
• Détection de secrets avertit quand un dépôt commit des identifiants comme des fichiers .env ou des clés privées.

Voir Entretien des serveurs.

• Le canvas est une carte en direct d’un projet : ses services, ses bases de données et les connexions entre eux. Changez d’environnement, créez une copie d’un projet, et voyez quel service chaque coéquipier a ouvert. Les services se joignent entre eux à <app>.railyard.internal et référencent les variables des autres avec ${{service.VAR}}.
• Sites statiques et fonctions peuvent être créés depuis le canvas.
• Modèles. Environ 200 applications open source figurent dans un catalogue public, et n’importe quel projet peut être publié comme modèle. Les secrets ne sont jamais publiés; ils sont demandés ou générés au moment du déploiement.
• Bouton Deploy to Railyard pour les README, qui ouvre une configuration préremplie sur le propre serveur du visiteur.
• Proxy TCP pour atteindre une base de données depuis l’extérieur, activé et désactivé depuis son panneau.

Voir Le canvas et Bouton de déploiement.

• Mise en veille après le délai d’inactivité de votre choix, et réveil à la prochaine requête. Les applications de staging et d’aperçu se mettent en veille après 30 minutes d’inactivité par défaut, les heures d’activité gardent une application en ligne seulement pendant les plages que vous définissez, et les applications uniquement worker se réveillent selon un horaire pour vider leurs files.
• Mise à l’échelle automatique des réplicas web entre un plancher et un plafond, selon la latence p95 ou le CPU, avec des plages planifiées qui ajoutent de la capacité avant un pic connu.
• Import depuis Heroku, Render, Fly.io et Railway avec un jeton d’API : processus, variables, bases de données avec leurs données, et domaines. Les importateurs Heroku, Render et Fly.io sont en bêta.
• Coûts lit votre vraie facture cloud, trouve les serveurs, disques et IP inutilisés, et alerte à 50 %, 80 % et 100 % d’un budget mensuel. Un plafond strict optionnel met en veille les applications hors production et bloque la création de nouveaux serveurs.
• Pages de statut publiques avec 90 jours de disponibilité.

Voir Coûts et économies et Importer depuis une autre plateforme.

Les applications Rails sont détectées à la création. Les workers sont trouvés dans le dépôt, les assets se construisent avec Propshaft, importmap, jsbundling ou cssbundling, Active Storage obtient un volume persistant, et chaque base de données de database.yml est créée, si bien que Solid Queue, Solid Cache et Solid Cable fonctionnent sur Rails 8 sans configuration.

Les applications Laravel avec laravel/octane s’exécutent sous Octane sur FrankenPHP, et celles avec laravel/reverb obtiennent un worker Reverb. Symfony et WordPress se construisent aussi sans Dockerfile.

Voir Rails et Laravel.

• Authentification unique (SSO) via OpenID Connect ou SAML 2.0, avec Google Workspace, Okta, Microsoft Entra, OneLogin et d’autres. Les domaines sont vérifiés par un enregistrement DNS, les nouveaux membres se joignent à leur première connexion avec le rôle que vous choisissez, et le SSO peut être exigé pour tous ceux de votre domaine.
• SCIM 2.0 ajoute et retire des membres depuis votre fournisseur d’identité.
• Score de sécurité sur 100, calculé à partir de dix vérifications, incluant la couverture de l’authentification à deux facteurs, les correctifs OS en attente, les ports ouverts, les certificats qui expirent et les sauvegardes non vérifiées. Chaque vérification pointe vers son correctif.
• Clés SSH d’équipe installées sur chaque serveur que l’équipe exploite, et retirées en moins d’une minute quand une clé ou un membre part.
• Serveur MCP pour les agents IA. Claude Code, Cursor et d’autres clients MCP utilisent les mêmes jetons d’API que la CLI. Les actions destructrices deviennent des demandes qu’un admin approuve d’abord.
• Paramètres de compte : changez votre courriel et votre mot de passe, exportez vos données en JSON, ou supprimez votre compte.

Voir Équipes et SSO et MCP.

• Serveurs de build. Donnez à un serveur le rôle de builder et il prend en charge la compilation, pour qu’un gros build n’entre jamais en concurrence avec le trafic en direct sur vos serveurs d’applications.
• Rebuilds plus rapides grâce à un cache de build partagé, et un plafond de mémoire pour qu’un gros build échoue proprement plutôt que d’épuiser le serveur.
• Les builds se rétablissent des échecs courants : images de base dépassées, anciens builds webpack, Node qui manque de mémoire, cas particuliers d’empaquetage Python et contraintes de version PHP. Quand un Dockerfile échoue malgré tout, Railyard réessaie avec Railpack en utilisant les versions fixées dans votre code.
• Dépôts multi-services. Un fichier compose ou un dépôt avec plusieurs Dockerfiles propose de créer tous les services en même temps, avec les entrepôts de données dont ils ont besoin.

• Alertes sur les métriques pour la latence p95, le taux de 5xx, la mémoire ou le CPU, vérifiées chaque minute, avec un suivi quand la situation revient à la normale.
• Logs d’accès : chaque requête qui passe par le proxy est journalisée avec méthode, chemin, statut, durée et client, et elle est cherchable avec les logs de votre application.
• OpenTelemetry : donnez à une application un point de terminaison OTLP et Railyard configure les variables standards OTEL_* et envoie ses propres métriques de CPU, de mémoire et de requêtes au même endroit.
• Vue des files de tâches (bêta) pour Sidekiq, Solid Queue, GoodJob, Resque et Delayed Job, avec réessai, abandon et une alerte sur l’arriéré.
• Rétention des logs par équipe, avec recherche sur n’importe quelle plage de temps et téléchargement en texte brut.

Voir Logs, métriques et alertes.

• Un déploiement est terminé quand les utilisateurs peuvent l’atteindre, pas quand le conteneur démarre. Railyard vérifie l’application à sa vraie URL HTTPS avant de basculer le trafic, et une simple redirection ne suffit plus à faire passer une application pour saine.
• Les boucles de plantage se mettent en pause. Un processus qui plante en boucle pendant dix minutes est arrêté plutôt que redémarré indéfiniment, et la page de l’application montre pourquoi il a planté. Restart le redémarre.
• Progression en direct pour les tâches longues. La création d’un serveur, les sauvegardes, les restaurations, les imports et les redimensionnements affichent leurs étapes, leur sortie récente et le temps restant, et continuent de s’exécuter si vous quittez la page.

Les dépôts sans Dockerfile se construisent maintenant automatiquement avec Cloud Native Buildpacks, en utilisant des couches d’exécution préconstruites plutôt qu’en compilant un langage depuis la source. Votre dépôt est lu de la même façon que Heroku le lit, donc une application qui migre n’a généralement besoin d’aucun changement.

Un Procfile déclare les types de processus et la commande de release. Les processus web et worker en démarrent, et l’entrée release: s’exécute avant que la nouvelle version reçoive du trafic.

Voir Méthodes de build.

• Connectez GitHub en installant l’application GitHub de Railyard une seule fois, puis choisissez des dépôts dans une liste. Les dépôts privés se clonent avec des jetons de courte durée, les push déploient, et les commits reçoivent une vérification de statut.
• Connectez GitLab, sur gitlab.com ou en autogéré, avec un jeton d’accès sous Équipe → Fournisseurs Git.
• Environnements d’aperçu pour chaque pull request et chaque merge request, supprimés à sa fermeture. Les environnements de staging peuvent être promus en production.
• Chaque déploiement échoué s’explique lui-même : la cause probable, le correctif et la ligne de log qui le montre, sur la page de déploiement, le tableau de bord et le canvas.

Voir Connecter GitHub et Environnements et aperçus.

• Équipes avec les rôles propriétaire, admin, développeur et observateur, et des membres qui peuvent être limités à des applications précises.
• Connexion à deux facteurs avec n’importe quelle application d’authentification, plus des codes de secours.
• Une API REST avec des jetons propres à chaque équipe, et un client en ligne de commande construit par-dessus.
• Notifications pour les déploiements, les serveurs hors ligne et les boucles de plantage, envoyées vers Slack, un webhook ou un courriel.
• Approbations de déploiement : les déploiements en production peuvent attendre l’approbation d’un admin.
• Journal d’activité de chaque déploiement, changement de configuration et action sur un serveur.

• Créez un serveur sur DigitalOcean, Hetzner, Vultr, AWS ou OVHcloud depuis le tableau de bord avec votre propre jeton d’API, ou ajoutez n’importe quel serveur Linux en SSH. Railyard termine la configuration, règle le pare-feu et le maintient à jour.
• Chaque application obtient un nom d’hôte et un certificat TLS dès qu’elle est déployée. Ajoutez des domaines personnalisés, servis directement ou redirigés vers le principal, avec le statut du certificat dans l’onglet Domains.
• Tâches planifiées avec historique d’exécution et bouton Run now.
• Métriques de serveur avec graphiques de CPU, de mémoire et de disque, et des alertes quand un disque se remplit ou que l’utilisation reste élevée.
• Mode maintenance par application.

Voir Ajouter un serveur.

Ajoutez un entrepôt de données à une application et Railyard l’exécute sur le même serveur, crée des identifiants réservés à cette application et configure les variables de connexion au prochain déploiement.

• Postgres (avec pgvector), MySQL, Redis, MongoDB, Elasticsearch, Memcached, RabbitMQ, InfluxDB et le stockage d’objets compatible S3.
• Sauvegardes selon un horaire avec une rétention à votre choix, restauration en un clic, et un vérificateur qui restaure chaque sauvegarde dans une base de données temporaire pour prouver qu’elle fonctionne.
• Volumes persistants pour les applications qui écrivent sur disque, avec leurs propres sauvegardes.

Voir Bases de données et sauvegardes.

Railyard déploie un dépôt Git sur un serveur à vous : il clone le code, le construit et diffuse le journal du build dans votre navigateur au fil de son exécution.

• Mises en production sans interruption. La nouvelle version démarre à côté de l’ancienne et ne reçoit du trafic qu’une fois qu’elle passe une vérification de disponibilité. Un échec de la vérification laisse l’ancienne version en service.
• Processus web et worker, chacun avec sa propre commande et son propre nombre de réplicas, plus une commande de release qui s’exécute avant que le trafic ne bascule.
• Variables d’environnement, chiffrées au repos et modifiables une à la fois ou collées sous forme de bloc .env.
• Retour arrière vers n’importe quelle version antérieure en un clic.
• Sources privées : clones authentifiés par jeton, sous-modules, arguments de build, secrets de build et images préconstruites depuis un registre privé.