Railshot

Railshot

AI deployment & operations platform

Distribuire una app web costruita in locale in ambienti cloud e on-premises predisposti, e poi gestirla.

Una piattaforma IA di deployment e operazioni che porta una app web costruita in locale in ambienti cloud o on-premises predisposti e continua a gestirla.

Dal 2026.09.28 al 2026.10.04 · Concluso

Progetto di squadra · il mio contributo: pianificazione e implementazione della CI, cluster CSP e interfaccia Ansible, operazioni, code review e integrazione del team

SoftBank Hackathon 2026 powered by KOREC & ProgatePartecipante alle preliminari · selezione per la finale annunciata il 2026.10.26 (al 2026.10.07)

WebImplementato · hackathon
Server MCPImplementato · remoto · locale

La schermata web e un proprio agente richiedono il deployment tramite la stessa API di prodotto.

Il prodotto da una richiesta di deployment accettata, attraverso controlli CI e pubblicazione delle immagini, fino a configurazione Git e rilascio con Argo CD su un target registrato e verifica dell’HTTPS pubblico. Il successo è registrato solo con una revisione applicata e un controllo pubblico; un esito che non può essere noto resta unknown.

Si invia un progetto dalla schermata web, o da un proprio agente IA collegato via MCP, e la piattaforma lo porta attraverso preparazione dei file di deployment, riparazione dei fallimenti, pubblicazione delle immagini, rilascio nell’ambiente e verifica dell’URL pubblico; dopo il deployment la stessa schermata mostra cronologia e log e gestisce aggiornamenti, arresti, riprese ed eliminazione. Un progetto di squadra.

Periodo di sviluppo dell’evento dal September 28, 2026 al October 4, 2026

La schermata web e il server MCP costruiti durante l’hackathon. L’MCP remoto accede con OAuth per inviare; le cartelle locali si inviano tramite l’MCP locale.

Architettura del prodotto · disegnata dai percorsi del codice al commit pubblico 645e28a

Invio → accettazione

La schermata web, l’MCP remoto e l’MCP locale chiamano la stessa API di prodotto, che registra una richiesta verificata come queued e risponde 202.

Utente del browserdati: cartella · ZIP · URL GitHubschermata web · cronologia · Insightsapps/dashboard
Sorgente e ambiente registrato si scelgono nella schermata web.
schermata web · cronologia · Insightsapps/dashboarddati: stessa API di prodotto · /api/v1validazione · target · accettazione 202apps/api
La schermata web chiama l’API di prodotto dalla stessa origine.
Client MCPdati: OAuth · deploy_repositoryOAuth MCP · deploy_repositoryagent/remote-mcp.js
L’MCP remoto si collega via OAuth e prende come input un repository GitHub pubblico.
OAuth MCP · deploy_repositoryagent/remote-mcp.jsdati: stessa API di prodottovalidazione · target · accettazione 202apps/api
Il server MCP remoto chiama la stessa API di deployment tramite il proprio client API interno.
railshot-local MCPdati: upload dello ZIP · deploy_local_projectvalidazione · target · accettazione 202apps/api
L’MCP stdio sul computer dell’utente comprime una cartella in ZIP e la carica. La sua sessione non è condivisa con la sessione OAuth remota.
validazione · target · accettazione 202apps/apidati: registrato come queued · 202stato dell’operation · binding della runapi/product-store.js
Input, target registrato, capacità e chiave di idempotenza vengono controllati; l’operation viene registrata come queued e si risponde 202. Un 202 significa accettato, non distribuito.
stato dell’operation · binding della runapi/product-store.jsdati: ordine di codacoda di deploy · 3 alla voltaapps/api
Prelevate in ordine di accettazione, entro il limite di deployment concorrenti (3 per impostazione predefinita).
stato dell’operation · binding della runapi/product-store.jsosservazione: stato del deployment · cronologiaschermata web · cronologia · Insightsapps/dashboard
La schermata web e gli strumenti MCP leggono gli stessi registri delle operation. L’ultimo tentativo e il deployment verificato attuale sono mostrati separatamente, e un’attività IA completata non è un successo di deployment.

Controlli CI → pubblicazione dell’immagine

Il codice di piattaforma fissato controlla il commit inviato, affida all’IA solo i fallimenti correggibili e pubblica solo immagini che hanno superato di nuovo gli stessi controlli.

coda di deploy · 3 alla voltaapps/apidati: source commitcommit sorgente · trailerapps/<tenant>/<app>
La sorgente inviata diventa un commit nel repository privato apps (con i trailer Railshot-Request e Railshot-Target), e il branch viene aggiornato senza force.
coda di deploy · 3 alla voltaapps/apiesecuzione · applicazione: workflow_dispatchloop · controlli di base L0–L3railshot-deploy.yml
Richiede un’esecuzione con tenant, app, source_commit e target_id. Se la risposta va persa, non viene reinviata; si cercano invece le esecuzioni per lo stesso commit.
commit sorgente · trailerapps/<tenant>/<app>dati: commit inviatoloop · controlli di base L0–L3railshot-deploy.yml
Viene fatto il checkout solo del commit inviato e del codice di piattaforma fissato (PLATFORM_REF).
riparazione SDK · solo fallimenti correggibilirailshot-deploy.ymldati: richiesta di correzione · condizionaleAI SDK provider
Viene chiamata solo per classi di errore correggibili e si ferma quando lo stesso errore si ripete o si raggiunge il limite di tentativi. Superamento o fallimento li decidono i controlli, non l’LLM.
release · pubblicazione GHCR · bindingrailshot-deploy.ymldati: pubblicazione delle immagini verificateGHCR
Dopo aver verificato il bundle che ha superato i controlli, le stesse immagini vengono pubblicate su GHCR. Nulla viene ricompilato.
binding dell’esecuzione CI · osservazioneapps/apiosservazione: esecuzione · lettura della pubblicazionerailshot-deploy.yml
Una pubblicazione conta solo se run id, commit sorgente, target e app corrispondono al registro accettato.
binding dell’esecuzione CI · osservazioneapps/apifallimento · esito ignoto: failed · publication_unverifiedstato dell’operation · binding della runapi/product-store.js
Un fallimento della CI o una pubblicazione non verificata viene registrato con la diagnostica e non passa al CD.

Applicazione → controllo pubblico

Applica tramite Git di config e Argo CD solo se la pubblicazione corrisponde al target registrato, e registra il successo solo dopo che l’indirizzo HTTPS pubblico registrato supera il controllo.

release · pubblicazione GHCR · bindingrailshot-deploy.ymldati: images.json · spec · verdict · manifestcd.js · deployPublishedapps/api
Il CD legge i file del registro di pubblicazione tramite un loader attendibile. La CI di per sé non crea risorse del cluster, URL o successi di deployment.
cd.js · deployPublishedapps/apiesecuzione · applicazione: apply · target registratoconfig attendibile · target registratogitops/bridge.py
Esegue gitops/bridge.py con la config attendibile solo se app e tenant registrati corrispondono al registro di pubblicazione.
commit · push · rilettura remotagitops/bridge.pydati: workload commit · pushRepo Git di config
Esegue il commit del solo workload.json nel percorso registrato di un branch dedicato, registra prima l’intenzione di push, esegue il push e rilegge la revisione remota. Un push incerto non viene ripetuto.
Repo Git di configdati: revisionApplication · controllo dell’AppProjectArgo CD
La revisione del repository di config a cui punta l’Application di Argo CD.
sync di Argo · osservazionegitops/bridge.pyesecuzione · applicazione: sync · osservazioneApplication · controllo dell’AppProjectArgo CD
Richiede una sync dopo aver controllato l’AppProject; l’osservazione legge soltanto, senza sync.
Application · controllo dell’AppProjectArgo CDesecuzione · applicazione: applicazioneworkload · ServiceCluster di app K3s
Applica il workload al cluster target registrato.
workload · ServiceCluster di app K3sdati: pull dell’immagine · digestGHCR
Scarica il digest pubblicato. Un GHCR privato richiede una credenziale di pull dedicata.
probe HTTPS pubblicagitops/bridge.pyosservazione: HTTPS healthURL HTTPS pubblico
Controlla solo l’indirizzo HTTPS di health registrato dall’operatore, senza redirect, per un 200 (e il JSON atteso, se impostato).
URL HTTPS pubblicodati: percorso pubblicoworkload · ServiceCluster di app K3s
Il percorso pubblico (LB, NodePort, certificato) varia per provider e target registrato.
cd.js · deployPublishedapps/apidati: succeeded · revision · URLstato dell’operation · binding della runapi/product-store.js
Registrato come succeeded solo con cd.deployed, una revisione, un controllo HTTPS pubblico riuscito, il suo orario e un URL valido.
cd.js · deployPublishedapps/apifallimento · esito ignoto: unknown · da riconciliarestato dell’operation · binding della runapi/product-store.js
Un esito che non può essere noto resta unknown; lo stesso apply non viene né reinviato né annullato.

Osservazione · non il verdetto

Metriche e probe non decidono il successo del deployment. I valori mancanti, obsoleti e falliti sono mostrati così come sono.

metrics observerapps/apiosservazione: query PromQLPrometheus
Legge up, probe_success e le serie dei Pod. I valori mancanti, obsoleti o falliti sono mostrati in quello stato e mai trasformati in 0.
Prometheusosservazione: scrape · probeworkload · ServiceCluster di app K3s
Scrape dell’exporter e probe HTTP. Queste metriche non servono a decidere il successo del deployment.
stato dell’operation · binding della runapi/product-store.jsosservazione: stato del deployment · cronologiaschermata web · cronologia · Insightsapps/dashboard
La schermata web e gli strumenti MCP leggono gli stessi registri delle operation. L’ultimo tentativo e il deployment verificato attuale sono mostrati separatamente, e un’attività IA completata non è un successo di deployment.
probe HTTPS pubblicagitops/bridge.pyosservazione: HTTPS healthURL HTTPS pubblico
Controlla solo l’indirizzo HTTPS di health registrato dall’operatore, senza redirect, per un 200 (e il JSON atteso, se impostato).

Tutte le connessioni con lo stesso peso. Scegliendo un flusso se ne evidenzia solo il percorso, con passi numerati.

Continua · direzione di sorgente, immagini e richieste
Tratteggiata · richiesta di esecuzione, applicazione o sync
Tratto lungo e punto · letture di stato, probe e metriche, separate dal verdetto
Tratteggio corto · un fallimento registrato o un esito ignoto
Linea nera spessa · il flusso scelto; i numeri danno l’ordine
Riquadro · un confine di titolarità, con il percorso sorgente nell’intestazione
Chip interno · un componente dentro quel confine
Riquadro tratteggiato · fuori dalla piattaforma
Contorno arancione · dove decide un modello

API di prodotto
Registri di deployment
Confine di esecuzione del CD
Ingresso · CI · target

L’immagine del October 2 (bc61a5a) in docs/architecture/README.md è storia dell’implementazione; questa architettura segue il codice di 645e28a. Provider e percorsi di rete variano per target registrato, e ciò non significa che ogni provider sia sempre attivo.

Railshot vocabulary

Invio → accettazione

Controlli CI → pubblicazione dell’immagine

Applicazione → controllo pubblico

Osservazione · non il verdetto