Railshot

Railshot

AI deployment & operations platform

Implantar um app web criado localmente em ambientes de nuvem e on-premises preparados e depois operá-lo.

Uma plataforma de IA de implantação e operação que leva um app web criado localmente a ambientes de nuvem ou on-premises preparados e continua a operá-lo.

2026.09.28 — 2026.10.04 · Concluído

Projeto em equipe · minha parte: planejamento e implementação da CI, clusters CSP e interface Ansible, operação, revisão de código da equipe e integração

SoftBank Hackathon 2026 powered by KOREC & ProgateParticipante da fase preliminar · seleção para a final a ser anunciada em 2026.10.26 (até 2026.10.07)

WebImplementado · hackathon
Servidor MCPImplementado · remoto · local

A tela web e um agente próprio pedem a implantação pela mesma API do produto.

O produto, desde uma requisição de implantação aceita, passando pelas verificações da CI e pela publicação da imagem, até a configuração no Git e a implantação pelo Argo CD em um destino registrado e a verificação HTTPS pública. O sucesso só é registrado com uma revisão aplicada e uma verificação pública; um resultado que não pode ser conhecido fica como unknown.

Um projeto enviado pela tela web, ou por um agente de IA próprio conectado via MCP, passa pela preparação dos arquivos de implantação, pelo reparo de falhas, pela publicação da imagem, pela implantação no ambiente e pela verificação da URL pública; depois da implantação, a mesma tela mostra histórico e logs e gerencia atualizações, paradas, retomadas e exclusões. Um projeto em equipe.

Período de desenvolvimento da competição: September 28, 2026 to October 4, 2026

A tela web e o servidor MCP construídos durante o hackathon. O MCP remoto faz login com OAuth para enviar; pastas locais são enviadas pelo MCP local.

Arquitetura do produto · desenhada a partir dos caminhos de código no commit público 645e28a

Enviar → aceitar

A tela web, o MCP remoto e o MCP local chamam a mesma API do produto, que registra uma requisição verificada como queued e responde 202.

Usuário do navegadordados: pasta · ZIP · URL do GitHubtela web · histórico · Insightsapps/dashboard
A fonte e um ambiente registrado são escolhidos na tela web.
tela web · histórico · Insightsapps/dashboarddados: mesma API do produto · /api/v1validar · destino · aceitação 202apps/api
A tela web chama a API do produto a partir da mesma origem.
Cliente MCPdados: OAuth · deploy_repositoryOAuth MCP · deploy_repositoryagent/remote-mcp.js
O MCP remoto se conecta via OAuth e recebe como entrada um repositório público do GitHub.
OAuth MCP · deploy_repositoryagent/remote-mcp.jsdados: mesma API do produtovalidar · destino · aceitação 202apps/api
O servidor MCP remoto chama a mesma API de implantação pelo seu cliente de API interno.
railshot-local MCPdados: upload de ZIP · deploy_local_projectvalidar · destino · aceitação 202apps/api
O MCP stdio no computador do usuário compacta uma pasta em ZIP e a envia. Sua sessão não é compartilhada com a sessão OAuth remota.
validar · destino · aceitação 202apps/apidados: registrado como queued · 202estado da operação · vinculação do runapi/product-store.js
Entrada, destino registrado, capacidade e chave de idempotência são verificados; a operação é registrada como queued e a resposta é 202. Um 202 significa aceito, não implantado.
estado da operação · vinculação do runapi/product-store.jsdados: ordem da filafila de implantação · 3 por vezapps/api
Retiradas na ordem de aceitação, dentro do limite de implantações simultâneas (3 por padrão).
estado da operação · vinculação do runapi/product-store.jsobservação: estado da implantação · históricotela web · histórico · Insightsapps/dashboard
A tela web e as ferramentas MCP leem os mesmos registros de operação. A tentativa mais recente e a implantação verificada atual aparecem separadas, e uma tarefa de IA concluída não é implantação bem-sucedida.

Verificações da CI → publicação da imagem

O código de plataforma fixado verifica o commit enviado, só passa à IA as falhas reparáveis e só publica imagens que passam de novo pelas mesmas verificações.

fila de implantação · 3 por vezapps/apidados: source commitcommit de origem · trailersapps/<tenant>/<app>
A fonte enviada vira um commit no repositório privado apps (com os trailers Railshot-Request e Railshot-Target), e o branch é atualizado sem force.
fila de implantação · 3 por vezapps/apiexecutar · aplicar: workflow_dispatchloop · verificações básicas L0–L3railshot-deploy.yml
Pede uma execução com tenant, app, source_commit e target_id. Se a resposta se perder, ela não é reenviada; em vez disso, as execuções do mesmo commit são buscadas.
commit de origem · trailersapps/<tenant>/<app>dados: commit enviadoloop · verificações básicas L0–L3railshot-deploy.yml
Só o commit enviado e o código de plataforma fixado (PLATFORM_REF) recebem checkout.
reparo via SDK · só falhas reparáveisrailshot-deploy.ymldados: pedido de reparo · condicionalAI SDK provider
Só é chamado para classes de falha reparáveis e para quando a mesma falha se repete ou o limite de tentativas é atingido. Aprovação ou falha é decidida pelas verificações, não pelo LLM.
versão · publicação no GHCR · vinculaçãorailshot-deploy.ymldados: publicar as imagens verificadasGHCR
Após verificar o bundle que passou nas verificações, as mesmas imagens são publicadas no GHCR. Nada é reconstruído.
vinculação da execução de CI · observaçãoapps/apiobservação: leitura de execução · publicaçãorailshot-deploy.yml
Uma publicação só conta se run id, commit de origem, destino e app correspondem ao registro aceito.
vinculação da execução de CI · observaçãoapps/apifalha · resultado desconhecido: failed · publication_unverifiedestado da operação · vinculação do runapi/product-store.js
Uma falha de CI ou uma publicação não verificada é registrada com diagnósticos e não é passada ao CD.

Aplicar → verificação pública

Só aplica pelo Git de config e pelo Argo CD quando a publicação corresponde ao destino registrado, e só registra sucesso depois que o endereço HTTPS público registrado passa na verificação.

versão · publicação no GHCR · vinculaçãorailshot-deploy.ymldados: images.json · spec · verdict · manifestcd.js · deployPublishedapps/api
O CD lê os arquivos do registro de publicação por um loader confiável. A CI por si só não cria recurso de cluster, URL nem sucesso de implantação.
cd.js · deployPublishedapps/apiexecutar · aplicar: aplicar · destino registradoconfig confiável · destino registradogitops/bridge.py
Executa gitops/bridge.py com a config confiável só se o app e o tenant registrados correspondem ao registro de publicação.
commit · push · releitura remotagitops/bridge.pydados: workload commit · pushRepositório Git de config
Faz commit só de workload.json no caminho registrado de um branch dedicado, registra primeiro a intenção de push, faz o push e relê a revisão remota. Um push incerto não é repetido.
Repositório Git de configdados: revisionverificação de Application · AppProjectArgo CD
A revisão do repositório de config para a qual a Application do Argo CD aponta.
sync do Argo · observaçãogitops/bridge.pyexecutar · aplicar: sync · observarverificação de Application · AppProjectArgo CD
Pede uma sync após verificar o AppProject; a observação só lê, sem sync.
verificação de Application · AppProjectArgo CDexecutar · aplicar: aplicarworkload · ServiceCluster de apps K3s
Aplica o workload ao cluster de destino registrado.
workload · ServiceCluster de apps K3sdados: pull da imagem · digestGHCR
Baixa o digest publicado. Um GHCR privado exige uma credencial de pull dedicada.
probe HTTPS públicogitops/bridge.pyobservação: HTTPS healthURL HTTPS pública
Verifica só o endereço HTTPS de health registrado pelo operador, sem redirecionamentos, esperando 200 (e o JSON esperado, se definido).
URL HTTPS públicadados: caminho públicoworkload · ServiceCluster de apps K3s
O caminho público (LB, NodePort, certificado) varia conforme o provedor e o destino registrado.
cd.js · deployPublishedapps/apidados: succeeded · revision · URLestado da operação · vinculação do runapi/product-store.js
Registrado como succeeded só com cd.deployed, uma revisão, uma verificação HTTPS pública bem-sucedida, seu horário e uma URL válida.
cd.js · deployPublishedapps/apifalha · resultado desconhecido: unknown · requer reconciliaçãoestado da operação · vinculação do runapi/product-store.js
Um resultado que não pode ser conhecido fica como unknown; a mesma aplicação não é reenviada nem revertida.

Observação · não é o veredito

Métricas e probes não decidem o sucesso da implantação. Valores ausentes, desatualizados e com falha aparecem como estão.

metrics observerapps/apiobservação: consulta PromQLPrometheus
Lê as séries up, probe_success e de Pods. Valores ausentes, desatualizados ou com falha aparecem nesse estado e nunca viram 0.
Prometheusobservação: scrape · probeworkload · ServiceCluster de apps K3s
Scrape de exporters e probe HTTP. Essas métricas não são usadas para decidir o sucesso da implantação.
estado da operação · vinculação do runapi/product-store.jsobservação: estado da implantação · históricotela web · histórico · Insightsapps/dashboard
A tela web e as ferramentas MCP leem os mesmos registros de operação. A tentativa mais recente e a implantação verificada atual aparecem separadas, e uma tarefa de IA concluída não é implantação bem-sucedida.
probe HTTPS públicogitops/bridge.pyobservação: HTTPS healthURL HTTPS pública
Verifica só o endereço HTTPS de health registrado pelo operador, sem redirecionamentos, esperando 200 (e o JSON esperado, se definido).

Todas as conexões com a mesma espessura. Escolha um fluxo para destacar só o caminho dele, com etapas numeradas.

Contínua · direção em que fluem fontes, imagens e requisições
Tracejada · pedido de execução, aplicação ou sync
Traço longo e ponto · leituras de estado, probes e métricas, separados do veredito
Traço curto · falha registrada ou resultado desconhecido
Linha preta grossa · o fluxo selecionado; os números dão a ordem
Caixa · fronteira proprietária, com o caminho de origem no cabeçalho
Chip interno · componente dessa fronteira
Caixa tracejada · fora da plataforma
Contorno laranja · onde um modelo decide

API do produto
Registros de implantação
Fronteira de execução do CD
Entrada · CI · destino

A figura de October 2 (bc61a5a) em docs/architecture/README.md é histórico de implementação; esta arquitetura segue o código de 645e28a. Provedores e caminhos de rede variam conforme o destino registrado, e isso não significa que todos os provedores estejam sempre ativos.

Railshot vocabulary

Enviar → aceitar

Verificações da CI → publicação da imagem

Aplicar → verificação pública

Observação · não é o veredito