DE
RAILSHOT.
Zurück zum Saal

Railshot

AI deployment & operations platform

Eine lokal gebaute Web-App in vorbereitete Cloud- und On-Premises-Umgebungen deployen und dann betreiben.

Eine KI-Plattform für Deployment und Betrieb, die eine lokal gebaute Web-App in vorbereitete Cloud- oder On-Premises-Umgebungen bringt und weiter betreibt.

2026.09.28 bis 2026.10.04 · Abgeschlossen

Teamprojekt · mein Anteil: CI-Planung und -Implementierung, CSP-Cluster und Ansible-Schnittstelle, Betrieb, Code-Review und Integration im Team

SoftBank Hackathon 2026 powered by KOREC & ProgateTeilnahme an der Vorrunde · Bekanntgabe der Finalauswahl am 2026.10.26 (Stand 2026.10.07)

  • WebImplementiert · Hackathon
  • MCP-ServerImplementiert · remote · lokal

Die Weboberfläche und ein eigener Agent fordern das Deployment über dieselbe Produkt-API an.

Das Produkt von der angenommenen Deployment-Anfrage über CI-Prüfungen und Image-Veröffentlichung bis zu Git-Konfiguration und Argo-CD-Rollout auf einem registrierten Ziel und der Verifikation des öffentlichen HTTPS. Erfolg wird nur mit angewandter Revision und öffentlicher Prüfung aufgezeichnet; ein Ergebnis, das nicht bekannt sein kann, bleibt unknown.

Ein Projekt wird über die Weboberfläche oder von einem eigenen, per MCP verbundenen KI-Agenten eingereicht, und die Plattform führt es durch Vorbereitung der Deployment-Dateien, Reparatur von Fehlschlägen, Image-Veröffentlichung, Rollout in die Umgebung und Verifikation der öffentlichen URL; nach dem Deployment zeigt dieselbe Oberfläche Verlauf und Logs und verwaltet Updates, Stopps, Wiederaufnahmen und Löschungen. Ein Teamprojekt.

Entwicklungszeitraum des Events von September 28, 2026 bis October 4, 2026

Die Weboberfläche und der MCP-Server, die während des Hackathons gebaut wurden. Das Remote-MCP meldet sich zum Einreichen per OAuth an; lokale Ordner werden über das lokale MCP eingereicht.

Produktarchitektur · gezeichnet nach den Codepfaden im öffentlichen Commit 645e28a
Produktarchitektur von RailshotKomponenten und Verbindungen des Produkts Railshot. Weboberfläche, Remote-OAuth-MCP und ein lokales MCP auf dem Rechner des Nutzers fordern das Deployment über dieselbe Produkt-API an, die einen Quell-Commit und einen CI-Lauf registriert. Die CI entscheidet anhand fester Prüfungen und veröffentlicht die geprüften Images in GHCR. Der CD-Adapter wendet über Config-Git und Argo CD nur an, wenn das registrierte Ziel zur Publikationsaufzeichnung passt, prüft dann die registrierte öffentliche HTTPS-Adresse und zeichnet das Ergebnis auf. Metriken sind Beobachtung, getrennt vom Urteil.Browser-NutzerOrdner · ZIP · GitHub-URLMCP-ClientChatGPT · Codex · Clauderailshot-local MCPRechner des Nutzers · stdioGHCRImages per DigestAI SDK providerCodex · Claude SDKConfig-Git-Reporegistrierte workload.jsonÖffentliche HTTPS-URLregistrierter Health-PfadPrometheusBetriebs-Control-VM · lesenapps/dashboardWeboberfläche · Verlauf · Insightsagent/remote-mcp.jsOAuth MCP · deploy_repositoryapps/apivalidieren · Ziel · 202-AnnahmeDeploy-Queue · 3 gleichzeitigCI-Lauf-Bindung · beobachtencd.js · deployPublishedmetrics observerapi/product-store.jsOperation-Zustand · Run-Bindunggitops/bridge.pyvertrauenswürdige Konfiguration · registriertes ZielCommit · Push · Remote-RücklesungArgo-Sync · beobachtenöffentliche HTTPS-ProbeArgo CDApplication · AppProject-Prüfungapps/<tenant>/<app>Quell-Commit · Trailerrailshot-deploy.ymlloop · Basisprüfungen L0–L3SDK-Reparatur · nur behebbare Fehlschlägedieselben Prüfungen → geprüftes BundleRelease · GHCR-Veröffentlichung · BindungK3s-App-Clusterworkload · ServiceRailshot-PlattformBetriebscluster · AWSGitHubprivates apps-Repo · ActionsRegistriertes Zielöffentlicher Pfad je Provider1 Ordner · ZIP · GitHub-URL · Browser-Nutzer → Weboberfläche · Verlauf · Insights12dieselbe Produkt-API · /api/v13 OAuth · deploy_repository · MCP-Client → OAuth MCP · deploy_repository34dieselbe Produkt-API5 ZIP-Upload · deploy_local_project · railshot-local MCP → validieren · Ziel · 202-Annahme56 als queued aufgezeichnet · 202 · validieren · Ziel · 202-Annahme → Operation-Zustand · Run-Bindung67 Reihenfolge der Queue · Operation-Zustand · Run-Bindung → Deploy-Queue · 3 gleichzeitig78Deployment-Zustand · Verlauf1source commit2workflow_dispatch3eingereichter Commit4Korrekturanfrage · bedingt5geprüfte Images veröffentlichen6Lauf · Publikation lesen7 failed · publication_unverified · CI-Lauf-Bindung · beobachten → Operation-Zustand · Run-Bindung71images.json · spec · verdict · manifest2apply · registriertes Ziel3workload commit · push4revision5Sync · Beobachten6anwenden7Image-Pull · Digest8HTTPS health9 öffentlicher Pfad · Öffentliche HTTPS-URL → workload · Service910 succeeded · revision · URL · cd.js · deployPublished → Operation-Zustand · Run-Bindung1011 unknown · Abgleich nötig · cd.js · deployPublished → Operation-Zustand · Run-Bindung111PromQL-Abfrage2scrape · probe3Deployment-Zustand · Verlauf4HTTPS health

Einreichen → annehmen

Weboberfläche, Remote-MCP und lokales MCP rufen dieselbe Produkt-API auf, die eine geprüfte Anfrage als queued aufzeichnet und mit 202 antwortet.

  1. Browser-NutzerOrdner · ZIP · GitHub-URLWeboberfläche · Verlauf · Insightsapps/dashboard

    Quelle und eine registrierte Umgebung werden in der Weboberfläche gewählt.

  2. Weboberfläche · Verlauf · Insightsapps/dashboarddieselbe Produkt-API · /api/v1validieren · Ziel · 202-Annahmeapps/api

    Die Weboberfläche ruft die Produkt-API vom selben Origin auf.

  3. MCP-ClientOAuth · deploy_repositoryOAuth MCP · deploy_repositoryagent/remote-mcp.js

    Das Remote-MCP verbindet sich über OAuth und nimmt ein öffentliches GitHub-Repository als Eingabe.

  4. OAuth MCP · deploy_repositoryagent/remote-mcp.jsdieselbe Produkt-APIvalidieren · Ziel · 202-Annahmeapps/api

    Der Remote-MCP-Server ruft dieselbe Deployment-API über seinen internen API-Client auf.

  5. railshot-local MCPZIP-Upload · deploy_local_projectvalidieren · Ziel · 202-Annahmeapps/api

    Das stdio-MCP auf dem Rechner des Nutzers packt einen Ordner als ZIP und lädt ihn hoch. Seine Session wird nicht mit der Remote-OAuth-Session geteilt.

  6. validieren · Ziel · 202-Annahmeapps/apials queued aufgezeichnet · 202Operation-Zustand · Run-Bindungapi/product-store.js

    Eingabe, registriertes Ziel, Kapazität und Idempotenzschlüssel werden geprüft; die Operation wird als queued aufgezeichnet und mit 202 beantwortet. Ein 202 bedeutet angenommen, nicht deployt.

  7. Operation-Zustand · Run-Bindungapi/product-store.jsReihenfolge der QueueDeploy-Queue · 3 gleichzeitigapps/api

    In der Reihenfolge der Annahme entnommen, innerhalb des Limits gleichzeitiger Deployments (standardmäßig 3).

  8. Operation-Zustand · Run-Bindungapi/product-store.jsDeployment-Zustand · VerlaufWeboberfläche · Verlauf · Insightsapps/dashboard

    Weboberfläche und MCP-Tools lesen dieselben Operation-Aufzeichnungen. Der letzte Versuch und das aktuell verifizierte Deployment werden getrennt gezeigt, und eine abgeschlossene KI-Aufgabe ist kein Deployment-Erfolg.

CI-Prüfungen → Image-Veröffentlichung

Fixierter Plattformcode prüft den eingereichten Commit, übergibt nur behebbare Fehlschläge an die KI und veröffentlicht nur Images, die dieselben Prüfungen erneut bestanden haben.

  1. Deploy-Queue · 3 gleichzeitigapps/apisource commitQuell-Commit · Trailerapps/<tenant>/<app>

    Die eingereichte Quelle wird zu einem Commit im privaten apps-Repository (mit den Trailern Railshot-Request und Railshot-Target), und der Branch wird ohne Force aktualisiert.

  2. Deploy-Queue · 3 gleichzeitigapps/apiworkflow_dispatchloop · Basisprüfungen L0–L3railshot-deploy.yml

    Fordert einen Lauf mit tenant, app, source_commit und target_id an. Geht die Antwort verloren, wird nicht erneut gesendet; stattdessen werden die Läufe zum selben Commit gesucht.

  3. Quell-Commit · Trailerapps/<tenant>/<app>eingereichter Commitloop · Basisprüfungen L0–L3railshot-deploy.yml

    Nur der eingereichte Commit und fixierter Plattformcode (PLATFORM_REF) werden ausgecheckt.

  4. SDK-Reparatur · nur behebbare Fehlschlägerailshot-deploy.ymlKorrekturanfrage · bedingtAI SDK provider

    Wird nur für behebbare Fehlerklassen aufgerufen und stoppt, wenn sich derselbe Fehler wiederholt oder das Versuchslimit erreicht ist. Über Bestehen oder Scheitern entscheiden die Prüfungen, nicht das LLM.

  5. Release · GHCR-Veröffentlichung · Bindungrailshot-deploy.ymlgeprüfte Images veröffentlichenGHCR

    Nach Verifikation des Bundles, das die Prüfungen bestanden hat, werden dieselben Images in GHCR veröffentlicht. Nichts wird neu gebaut.

  6. CI-Lauf-Bindung · beobachtenapps/apiLauf · Publikation lesenrailshot-deploy.yml

    Eine Publikation zählt nur, wenn Run-ID, Quell-Commit, Ziel und App mit der angenommenen Aufzeichnung übereinstimmen.

  7. CI-Lauf-Bindung · beobachtenapps/apifailed · publication_unverifiedOperation-Zustand · Run-Bindungapi/product-store.js

    Ein CI-Fehlschlag oder eine nicht verifizierte Publikation wird mit Diagnose aufgezeichnet und nicht an CD weitergegeben.

Anwenden → öffentliche Prüfung

Wendet über Config-Git und Argo CD nur an, wenn die Publikation zum registrierten Ziel passt, und zeichnet Erfolg erst auf, wenn die registrierte öffentliche HTTPS-Adresse die Prüfung besteht.

  1. Release · GHCR-Veröffentlichung · Bindungrailshot-deploy.ymlimages.json · spec · verdict · manifestcd.js · deployPublishedapps/api

    CD liest die Dateien der Publikationsaufzeichnung über einen vertrauenswürdigen Loader. CI selbst erzeugt keine Cluster-Ressource, keine URL und keinen Deployment-Erfolg.

  2. cd.js · deployPublishedapps/apiapply · registriertes Zielvertrauenswürdige Konfiguration · registriertes Zielgitops/bridge.py

    Führt gitops/bridge.py mit der vertrauenswürdigen Konfiguration nur aus, wenn registrierte App und Tenant mit der Publikationsaufzeichnung übereinstimmen.

  3. Commit · Push · Remote-Rücklesunggitops/bridge.pyworkload commit · pushConfig-Git-Repo

    Committet nur workload.json am registrierten Pfad eines dedizierten Branches, hält zuerst die Push-Absicht fest, pusht und liest die Remote-Revision zurück. Ein unsicherer Push wird nicht wiederholt.

  4. Config-Git-ReporevisionApplication · AppProject-PrüfungArgo CD

    Die Revision des Config-Repositorys, auf die die Argo-CD-Application zeigt.

  5. Argo-Sync · beobachtengitops/bridge.pySync · BeobachtenApplication · AppProject-PrüfungArgo CD

    Fordert nach Prüfung des AppProject einen Sync an; das Beobachten liest nur, ohne Sync.

  6. Application · AppProject-PrüfungArgo CDanwendenworkload · ServiceK3s-App-Cluster

    Wendet den Workload auf den registrierten Ziel-Cluster an.

  7. workload · ServiceK3s-App-ClusterImage-Pull · DigestGHCR

    Zieht den veröffentlichten Digest. Ein privates GHCR braucht eigene Pull-Zugangsdaten.

  8. öffentliche HTTPS-Probegitops/bridge.pyHTTPS healthÖffentliche HTTPS-URL

    Prüft nur die vom Operator registrierte HTTPS-Health-Adresse, ohne Weiterleitungen, auf 200 (und, falls gesetzt, das erwartete JSON).

  9. Öffentliche HTTPS-URLöffentlicher Pfadworkload · ServiceK3s-App-Cluster

    Der öffentliche Pfad (LB, NodePort, Zertifikat) unterscheidet sich je nach Provider und registriertem Ziel.

  10. cd.js · deployPublishedapps/apisucceeded · revision · URLOperation-Zustand · Run-Bindungapi/product-store.js

    Als succeeded aufgezeichnet nur mit cd.deployed, einer Revision, einer erfolgreichen öffentlichen HTTPS-Prüfung, deren Zeitpunkt und einer gültigen URL.

  11. cd.js · deployPublishedapps/apiunknown · Abgleich nötigOperation-Zustand · Run-Bindungapi/product-store.js

    Ein Ergebnis, das nicht bekannt sein kann, bleibt unknown; dasselbe Apply wird weder erneut gesendet noch zurückgerollt.

Beobachtung · nicht das Urteil

Metriken und Probes entscheiden nicht über den Deployment-Erfolg. Fehlende, veraltete und fehlgeschlagene Werte werden so gezeigt, wie sie sind.

  1. metrics observerapps/apiPromQL-AbfragePrometheus

    Liest up, probe_success und Pod-Reihen. Fehlende, veraltete oder fehlgeschlagene Werte werden in diesem Zustand gezeigt und nie zu 0 gemacht.

  2. Prometheusscrape · probeworkload · ServiceK3s-App-Cluster

    Exporter-Scrape und HTTP-Probe. Diese Metriken entscheiden nicht über den Deployment-Erfolg.

  3. Operation-Zustand · Run-Bindungapi/product-store.jsDeployment-Zustand · VerlaufWeboberfläche · Verlauf · Insightsapps/dashboard

    Weboberfläche und MCP-Tools lesen dieselben Operation-Aufzeichnungen. Der letzte Versuch und das aktuell verifizierte Deployment werden getrennt gezeigt, und eine abgeschlossene KI-Aufgabe ist kein Deployment-Erfolg.

  4. öffentliche HTTPS-Probegitops/bridge.pyHTTPS healthÖffentliche HTTPS-URL

    Prüft nur die vom Operator registrierte HTTPS-Health-Adresse, ohne Weiterleitungen, auf 200 (und, falls gesetzt, das erwartete JSON).

Alle Verbindungen in gleicher Stärke. Wird ein Ablauf gewählt, ist nur sein Pfad hervorgehoben, mit nummerierten Schritten.

  • Durchgezogen · Richtung, in der Quellcode, Images und Anfragen fließen
  • Gestrichelt · Ausführungsanfrage, Anwenden oder Sync
  • Lang strichpunktiert · Statusabfragen, Probes und Metriken, getrennt vom Urteil
  • Kurz gestrichelt · ein aufgezeichneter Fehlschlag oder ein unbekanntes Ergebnis
  • Dicke schwarze Linie · der gewählte Ablauf; Nummern geben die Reihenfolge an
  • Kasten · eine Besitzgrenze, ihr Quellpfad in der Kopfzeile
  • Innerer Chip · eine Komponente innerhalb dieser Grenze
  • Gestrichelter Kasten · außerhalb der Plattform
  • Orange Umrandung · wo ein Modell entscheidet
  • Produkt-API
  • Deployment-Aufzeichnungen
  • CD-Ausführungsgrenze
  • Eintritt · CI · Ziel

Das Bild vom October 2 (bc61a5a) in docs/architecture/README.md ist Implementierungsgeschichte; diese Architektur folgt dem Code von 645e28a. Provider und Netzwerkpfade unterscheiden sich je nach registriertem Ziel, und das bedeutet nicht, dass jeder Provider immer aktiv ist.