Railshot

Railshot

AI deployment & operations platform

Deploy a locally built web app to prepared cloud and on-premises environments, then run it.

An AI deployment and operations platform that takes a web app built locally to prepared cloud or on-premises environments and keeps running it.

2026.09.28 — 2026.10.04 · Completed

Team project · my part: CI planning and implementation, CSP clusters and Ansible interface, operations, team code review and integration

SoftBank Hackathon 2026 powered by KOREC & ProgatePreliminary participant · finals selection — be announced 2026.10.26 (as of 2026.10.07)

WebImplemented · hackathon
MCP serverImplemented · remote · local

The web screen and your own agent request deployment through the same product API.

The product from an accepted deployment request, through CI checks and image publication, to Git configuration and Argo CD rollout on a registered target and public HTTPS verification. Success is recorded only with both an applied revision and a public check; an outcome that cannot be known stays unknown.

Submit a project from the web screen, or from your own AI agent connected over MCP, and it carries through deployment file preparation, failure repair, image publication, environment rollout and public URL verification; after deployment the same screen shows history and logs and manages updates, stops, resumes and deletion. A team project.

Event development window September 28, 2026 to October 4, 2026

The web screen and MCP server built during the hackathon. Remote MCP signs in with OAuth to submit; local folders are submitted through the local MCP.

Product architecture · drawn from the code paths at public commit 645e28a

Submit → accept

The web screen, the remote MCP and the local MCP call the same product API, which records a checked request as queued and answers 202.

Browser userdata: folder · ZIP · GitHub URLweb screen · history · Insightsapps/dashboard
The source and a registered environment are chosen on the web screen.
web screen · history · Insightsapps/dashboarddata: same product API · /api/v1validate · target · 202 acceptapps/api
The web screen calls the product API from the same origin.
MCP clientdata: OAuth · deploy_repositoryOAuth MCP · deploy_repositoryagent/remote-mcp.js
The remote MCP connects over OAuth and takes a public GitHub repository as input.
OAuth MCP · deploy_repositoryagent/remote-mcp.jsdata: same product APIvalidate · target · 202 acceptapps/api
The remote MCP server calls the same deployment API through its internal API client.
railshot-local MCPdata: ZIP upload · deploy_local_projectvalidate · target · 202 acceptapps/api
The stdio MCP on the user’s computer zips a folder and uploads it. Its session is not shared with the remote OAuth session.
validate · target · 202 acceptapps/apidata: recorded queued · 202operation state · run bindingapi/product-store.js
Input, registered target, capacity and idempotency key are checked; the operation is recorded as queued and answered with 202. A 202 means accepted, not deployed.
operation state · run bindingapi/product-store.jsdata: queue orderdeploy queue · 3 at a timeapps/api
Taken in order of acceptance, within the concurrent deployment limit (3 by default).
operation state · run bindingapi/product-store.jsobservation: deployment state · historyweb screen · history · Insightsapps/dashboard
The web screen and the MCP tools read the same operation records. The latest attempt and the current verified deployment are shown separately, and a finished AI task is not deployment success.

CI checks → image publish

Pinned platform code checks the submitted commit, hands only fixable failures to AI, and publishes only images that passed the same checks again.

deploy queue · 3 at a timeapps/apidata: source commitsource commit · trailersapps/<tenant>/<app>
The submitted source becomes a commit in the private apps repository (with Railshot-Request and Railshot-Target trailers), and the branch is updated without force.
deploy queue · 3 at a timeapps/apirun · apply: workflow_dispatchloop · baseline checks L0–L3railshot-deploy.yml
Requests a run with tenant, app, source_commit and target_id. If the response is lost, it is not sent again; the runs for the same commit are searched instead.
source commit · trailersapps/<tenant>/<app>data: submitted commitloop · baseline checks L0–L3railshot-deploy.yml
Only the submitted commit and pinned platform code (PLATFORM_REF) are checked out.
SDK repair · fixable failures onlyrailshot-deploy.ymldata: repair request · conditionalAI SDK provider
Called only for fixable failure classes, and stopped when the same failure repeats or the attempt limit is reached. Pass or fail is decided by the checks, not by the LLM.
release · GHCR publish · bindingrailshot-deploy.ymldata: publish checked imagesGHCR
After verifying the bundle that passed the checks, the same images are published to GHCR. Nothing is rebuilt.
CI run binding · observeapps/apiobservation: run · publication readrailshot-deploy.yml
A publication counts only when its run id, source commit, target and app match the accepted record.
CI run binding · observeapps/apifailure · unknown outcome: failed · publication_unverifiedoperation state · run bindingapi/product-store.js
A CI failure or an unverified publication is recorded with diagnostics and is not passed to CD.

Apply → public check

Applies through config Git and Argo CD only when the publication matches the registered target, and records success only after the registered public HTTPS address checks out.

release · GHCR publish · bindingrailshot-deploy.ymldata: images.json · spec · verdict · manifestcd.js · deployPublishedapps/api
CD reads the publication record’s files through a trusted loader. CI itself creates no cluster resource, URL or deployment success.
cd.js · deployPublishedapps/apirun · apply: apply · registered targettrusted config · registered targetgitops/bridge.py
Runs gitops/bridge.py with the trusted config only when the registered app and tenant match the publication record.
commit · push · remote readbackgitops/bridge.pydata: workload commit · pushConfig Git repo
Commits only workload.json at the registered path of a dedicated branch, records the push intent first, pushes, and reads the remote revision back. An uncertain push is not repeated.
Config Git repodata: revisionApplication · AppProject checkArgo CD
The config repository revision that the Argo CD Application points to.
Argo sync · observegitops/bridge.pyrun · apply: sync · observeApplication · AppProject checkArgo CD
Requests a sync after checking the AppProject; observing only reads, without a sync.
Application · AppProject checkArgo CDrun · apply: applyworkload · ServiceK3s app cluster
Applies the workload to the registered target cluster.
workload · ServiceK3s app clusterdata: image pull · digestGHCR
Pulls the published digest. A private GHCR needs a dedicated pull credential.
public HTTPS probegitops/bridge.pyobservation: HTTPS healthPublic HTTPS URL
Checks only the operator-registered HTTPS health address, without redirects, for 200 (and the expected JSON if set).
Public HTTPS URLdata: public pathworkload · ServiceK3s app cluster
The public path (LB, NodePort, certificate) differs by provider and registered target.
cd.js · deployPublishedapps/apidata: succeeded · revision · URLoperation state · run bindingapi/product-store.js
Recorded as succeeded only with cd.deployed, a revision, a successful public HTTPS check, its time and a valid URL.
cd.js · deployPublishedapps/apifailure · unknown outcome: unknown · needs reconciliationoperation state · run bindingapi/product-store.js
An outcome that cannot be known stays unknown; the same apply is neither re-sent nor rolled back.

Observation · not the verdict

Metrics and probes do not decide deployment success. Missing, stale and failed values are shown as they are.

metrics observerapps/apiobservation: PromQL queryPrometheus
Reads up, probe_success and Pod series. Missing, stale or failed values are shown in that state and never turned into 0.
Prometheusobservation: scrape · probeworkload · ServiceK3s app cluster
Exporter scrape and HTTP probe. These metrics are not used to decide deployment success.
operation state · run bindingapi/product-store.jsobservation: deployment state · historyweb screen · history · Insightsapps/dashboard
The web screen and the MCP tools read the same operation records. The latest attempt and the current verified deployment are shown separately, and a finished AI task is not deployment success.
public HTTPS probegitops/bridge.pyobservation: HTTPS healthPublic HTTPS URL
Checks only the operator-registered HTTPS health address, without redirects, for 200 (and the expected JSON if set).

Every connection at the same weight. Pick a flow to highlight only its path, with numbered steps.

Solid · the direction source, images and requests flow
Dashed · run request, apply or sync
Long dash-dot · status reads, probes and metrics, separate from the verdict
Short dash · a recorded failure or unknown outcome
Heavy black line · the selected flow; numbers give the order
Box · an owning boundary, its source path in the header
Inner chip · a component inside that boundary
Dashed box · outside the platform
Orange outline · where a model decides

Product API
Deployment records
CD execution boundary
Entry · CI · target

The October 2 (bc61a5a) picture in docs/architecture/README.md is implementation history; this architecture follows the 645e28a code. Providers and network paths differ by registered target, and this does not mean every provider is always on.

Railshot vocabulary

Submit → accept

CI checks → image publish

Apply → public check

Observation · not the verdict