FR
RAILSHOT.
Retour à la salle

Railshot

AI deployment & operations platform

Déployer une application web construite en local sur des environnements cloud et sur site préparés, puis l’exploiter.

Une plateforme IA de déploiement et d’exploitation qui mène une application web construite en local vers des environnements cloud ou sur site préparés, puis continue de l’exploiter.

2026.09.28 — 2026.10.04 · Terminé

Projet d’équipe · ma contribution : conception et implémentation de la CI, clusters CSP et interface Ansible, exploitation, revue de code de l’équipe et intégration

SoftBank Hackathon 2026 powered by KOREC & ProgateParticipant aux préliminaires · sélection pour la finale annoncée le 2026.10.26 (au 2026.10.07)

  • WebImplémenté · hackathon
  • Serveur MCPImplémenté · distant · local

L’écran web et un agent personnel demandent le déploiement par la même API produit.

Le produit, d’une demande de déploiement acceptée jusqu’à la vérification HTTPS publique, en passant par les contrôles CI et la publication de l’image, puis la configuration Git et le déploiement Argo CD sur une cible enregistrée. Le succès n’est consigné qu’avec à la fois une révision appliquée et un contrôle public ; une issue impossible à connaître reste unknown.

Un projet soumis depuis l’écran web, ou depuis un agent IA personnel connecté via MCP, passe par la préparation des fichiers de déploiement, la réparation des échecs, la publication de l’image, le déploiement dans l’environnement et la vérification de l’URL publique ; après le déploiement, le même écran affiche historique et journaux et gère mises à jour, arrêts, reprises et suppressions. Un projet d’équipe.

Période de développement de la compétition : September 28, 2026 to October 4, 2026

L’écran web et le serveur MCP construits pendant le hackathon. Le MCP distant se connecte par OAuth pour soumettre ; les dossiers locaux sont soumis par le MCP local.

Architecture du produit · tracée d’après les chemins de code au commit public 645e28a
Architecture du produit RailshotComposants et connexions du produit Railshot. L’écran web, le MCP OAuth distant et un MCP local sur l’ordinateur de l’utilisateur demandent le déploiement par la même API produit, qui enregistre un commit source et une exécution CI. La CI décide par des contrôles fixes et publie les images vérifiées sur GHCR. L’adaptateur CD n’applique via le Git de config et Argo CD que si la cible enregistrée correspond à l’enregistrement de publication, puis vérifie l’adresse HTTPS publique enregistrée et consigne l’issue. Les métriques sont de l’observation, distincte du verdict.Utilisateur du navigateurdossier · ZIP · URL GitHubClient MCPChatGPT · Codex · Clauderailshot-local MCPordinateur de l’utilisateur · stdioGHCRimages par digestAI SDK providerCodex · Claude SDKDépôt Git de configworkload.json enregistréURL HTTPS publiquechemin health enregistréPrometheusVM de contrôle d’exploitation · lectureapps/dashboardécran web · historique · Insightsagent/remote-mcp.jsOAuth MCP · deploy_repositoryapps/apivalider · cible · acceptation 202file de déploiement · 3 à la foisliaison à l’exécution CI · observationcd.js · deployPublishedmetrics observerapi/product-store.jsétat de l’opération · liaison au rungitops/bridge.pyconfig de confiance · cible enregistréecommit · push · relecture distantesync Argo · observationsonde HTTPS publiqueArgo CDcontrôle Application · AppProjectapps/<tenant>/<app>commit source · trailersrailshot-deploy.ymlboucle · contrôles de base L0–L3réparation SDK · échecs réparables seulementmêmes contrôles → bundle testéversion · publication GHCR · liaisonCluster d’applications K3sworkload · ServicePlateforme Railshotcluster d’exploitation · AWSGitHubdépôt apps privé · ActionsCible enregistréechemin public par fournisseur1 dossier · ZIP · URL GitHub · Utilisateur du navigateur → écran web · historique · Insights12même API produit · /api/v13 OAuth · deploy_repository · Client MCP → OAuth MCP · deploy_repository34même API produit5 envoi ZIP · deploy_local_project · railshot-local MCP → valider · cible · acceptation 20256 consigné queued · 202 · valider · cible · acceptation 202 → état de l’opération · liaison au run67 ordre de la file · état de l’opération · liaison au run → file de déploiement · 3 à la fois78état du déploiement · historique1source commit2workflow_dispatch3commit soumis4demande de réparation · conditionnelle5publier les images vérifiées6lecture exécution · publication7 failed · publication_unverified · liaison à l’exécution CI · observation → état de l’opération · liaison au run71images.json · spec · verdict · manifest2appliquer · cible enregistrée3workload commit · push4revision5sync · observer6appliquer7pull de l’image · digest8HTTPS health9 chemin public · URL HTTPS publique → workload · Service910 succeeded · revision · URL · cd.js · deployPublished → état de l’opération · liaison au run1011 unknown · rapprochement nécessaire · cd.js · deployPublished → état de l’opération · liaison au run111requête PromQL2scrape · probe3état du déploiement · historique4HTTPS health

Soumettre → accepter

L’écran web, le MCP distant et le MCP local appellent la même API produit, qui consigne une requête vérifiée comme queued et répond 202.

  1. Utilisateur du navigateurdossier · ZIP · URL GitHubécran web · historique · Insightsapps/dashboard

    La source et un environnement enregistré sont choisis sur l’écran web.

  2. écran web · historique · Insightsapps/dashboardmême API produit · /api/v1valider · cible · acceptation 202apps/api

    L’écran web appelle l’API produit depuis la même origine.

  3. Client MCPOAuth · deploy_repositoryOAuth MCP · deploy_repositoryagent/remote-mcp.js

    Le MCP distant se connecte via OAuth et prend en entrée un dépôt GitHub public.

  4. OAuth MCP · deploy_repositoryagent/remote-mcp.jsmême API produitvalider · cible · acceptation 202apps/api

    Le serveur MCP distant appelle la même API de déploiement par son client API interne.

  5. railshot-local MCPenvoi ZIP · deploy_local_projectvalider · cible · acceptation 202apps/api

    Le MCP stdio sur l’ordinateur de l’utilisateur zippe un dossier et l’envoie. Sa session n’est pas partagée avec la session OAuth distante.

  6. valider · cible · acceptation 202apps/apiconsigné queued · 202état de l’opération · liaison au runapi/product-store.js

    Entrée, cible enregistrée, capacité et clé d’idempotence sont vérifiées ; l’opération est consignée comme queued et la réponse est 202. Un 202 signifie accepté, pas déployé.

  7. état de l’opération · liaison au runapi/product-store.jsordre de la filefile de déploiement · 3 à la foisapps/api

    Prises dans l’ordre d’acceptation, dans la limite de déploiements simultanés (3 par défaut).

  8. état de l’opération · liaison au runapi/product-store.jsétat du déploiement · historiqueécran web · historique · Insightsapps/dashboard

    L’écran web et les outils MCP lisent les mêmes enregistrements d’opération. La dernière tentative et le déploiement vérifié actuel sont affichés séparément, et une tâche IA terminée n’est pas un déploiement réussi.

Contrôles CI → publication de l’image

Le code de plateforme fixé contrôle le commit soumis, ne confie à l’IA que les échecs réparables et ne publie que les images qui repassent les mêmes contrôles.

  1. file de déploiement · 3 à la foisapps/apisource commitcommit source · trailersapps/<tenant>/<app>

    La source soumise devient un commit dans le dépôt privé apps (avec les trailers Railshot-Request et Railshot-Target), et la branche est mise à jour sans force.

  2. file de déploiement · 3 à la foisapps/apiworkflow_dispatchboucle · contrôles de base L0–L3railshot-deploy.yml

    Demande une exécution avec tenant, app, source_commit et target_id. Si la réponse est perdue, elle n’est pas renvoyée ; les exécutions du même commit sont recherchées à la place.

  3. commit source · trailersapps/<tenant>/<app>commit soumisboucle · contrôles de base L0–L3railshot-deploy.yml

    Seuls le commit soumis et le code de plateforme fixé (PLATFORM_REF) sont extraits.

  4. réparation SDK · échecs réparables seulementrailshot-deploy.ymldemande de réparation · conditionnelleAI SDK provider

    Appelée seulement pour les classes d’échec réparables, et arrêtée quand le même échec se répète ou que la limite de tentatives est atteinte. Réussite ou échec sont décidés par les contrôles, pas par le LLM.

  5. version · publication GHCR · liaisonrailshot-deploy.ymlpublier les images vérifiéesGHCR

    Après vérification du bundle qui a passé les contrôles, les mêmes images sont publiées sur GHCR. Rien n’est reconstruit.

  6. liaison à l’exécution CI · observationapps/apilecture exécution · publicationrailshot-deploy.yml

    Une publication ne compte que si son run id, son commit source, sa cible et son app correspondent à l’enregistrement accepté.

  7. liaison à l’exécution CI · observationapps/apifailed · publication_unverifiedétat de l’opération · liaison au runapi/product-store.js

    Un échec de CI ou une publication non vérifiée est consigné avec des diagnostics et n’est pas transmis à la CD.

Appliquer → contrôle public

N’applique via le Git de config et Argo CD que si la publication correspond à la cible enregistrée, et ne consigne le succès qu’après validation de l’adresse HTTPS publique enregistrée.

  1. version · publication GHCR · liaisonrailshot-deploy.ymlimages.json · spec · verdict · manifestcd.js · deployPublishedapps/api

    La CD lit les fichiers de l’enregistrement de publication par un chargeur de confiance. La CI elle-même ne crée ni ressource de cluster, ni URL, ni succès de déploiement.

  2. cd.js · deployPublishedapps/apiappliquer · cible enregistréeconfig de confiance · cible enregistréegitops/bridge.py

    Exécute gitops/bridge.py avec la config de confiance seulement si l’app et le tenant enregistrés correspondent à l’enregistrement de publication.

  3. commit · push · relecture distantegitops/bridge.pyworkload commit · pushDépôt Git de config

    Ne commite que workload.json au chemin enregistré d’une branche dédiée, consigne d’abord l’intention de push, pousse, puis relit la révision distante. Un push incertain n’est pas répété.

  4. Dépôt Git de configrevisioncontrôle Application · AppProjectArgo CD

    La révision du dépôt de config vers laquelle pointe l’Application Argo CD.

  5. sync Argo · observationgitops/bridge.pysync · observercontrôle Application · AppProjectArgo CD

    Demande une sync après contrôle de l’AppProject ; l’observation ne fait que lire, sans sync.

  6. contrôle Application · AppProjectArgo CDappliquerworkload · ServiceCluster d’applications K3s

    Applique le workload au cluster cible enregistré.

  7. workload · ServiceCluster d’applications K3spull de l’image · digestGHCR

    Tire le digest publié. Un GHCR privé exige un identifiant de pull dédié.

  8. sonde HTTPS publiquegitops/bridge.pyHTTPS healthURL HTTPS publique

    Ne vérifie que l’adresse HTTPS de health enregistrée par l’opérateur, sans redirection, pour un 200 (et le JSON attendu s’il est défini).

  9. URL HTTPS publiquechemin publicworkload · ServiceCluster d’applications K3s

    Le chemin public (LB, NodePort, certificat) diffère selon le fournisseur et la cible enregistrée.

  10. cd.js · deployPublishedapps/apisucceeded · revision · URLétat de l’opération · liaison au runapi/product-store.js

    Consigné comme succeeded seulement avec cd.deployed, une révision, un contrôle HTTPS public réussi, son heure et une URL valide.

  11. cd.js · deployPublishedapps/apiunknown · rapprochement nécessaireétat de l’opération · liaison au runapi/product-store.js

    Une issue impossible à connaître reste unknown ; la même application n’est ni renvoyée ni annulée.

Observation · pas le verdict

Métriques et sondes ne décident pas du succès du déploiement. Les valeurs manquantes, périmées et en échec sont affichées telles quelles.

  1. metrics observerapps/apirequête PromQLPrometheus

    Lit les séries up, probe_success et Pod. Les valeurs manquantes, périmées ou en échec sont affichées dans cet état et jamais converties en 0.

  2. Prometheusscrape · probeworkload · ServiceCluster d’applications K3s

    Scrape des exporters et sonde HTTP. Ces métriques ne servent pas à décider du succès du déploiement.

  3. état de l’opération · liaison au runapi/product-store.jsétat du déploiement · historiqueécran web · historique · Insightsapps/dashboard

    L’écran web et les outils MCP lisent les mêmes enregistrements d’opération. La dernière tentative et le déploiement vérifié actuel sont affichés séparément, et une tâche IA terminée n’est pas un déploiement réussi.

  4. sonde HTTPS publiquegitops/bridge.pyHTTPS healthURL HTTPS publique

    Ne vérifie que l’adresse HTTPS de health enregistrée par l’opérateur, sans redirection, pour un 200 (et le JSON attendu s’il est défini).

Toutes les connexions avec la même épaisseur. Choisissez un flux pour ne mettre en évidence que son chemin, avec des étapes numérotées.

  • Trait plein · sens de circulation des sources, images et requêtes
  • Tirets · demande d’exécution, application ou sync
  • Trait mixte long · lectures d’état, sondes et métriques, distinctes du verdict
  • Tiret court · échec consigné ou issue inconnue
  • Trait noir épais · le flux sélectionné ; les numéros donnent l’ordre
  • Cadre · frontière propriétaire, chemin source dans l’en-tête
  • Pastille intérieure · composant de cette frontière
  • Cadre en tirets · hors de la plateforme
  • Contour orange · là où un modèle décide
  • API produit
  • Enregistrements de déploiement
  • Frontière d’exécution CD
  • Entrée · CI · cible

Le schéma du October 2 (bc61a5a) dans docs/architecture/README.md relève de l’historique d’implémentation ; cette architecture suit le code de 645e28a. Fournisseurs et chemins réseau diffèrent selon la cible enregistrée, et cela ne signifie pas que chaque fournisseur est toujours actif.