From prompt to running stack — in four phases.
SprintOS is a compiler, not a wrapper. Every run produces the same artifact, the same provisioning order, the same wired runtime.
Define
Write a declarative stack config, or describe what you want in natural language. The AI generator emits a typed, validated YAML you can review and version-control.
# stack.yaml
databases:
- id: orders-db
type: postgres
version: "16"
migrations: ./db/migrations
messaging:
- id: events
type: kafka
topics: [orders.created, orders.shipped]
mocks:
- id: payments
endpoint: /v1/charge
response: { status: "succeeded" }Compile
SprintOS resolves the dependency graph, validates schemas, plans migrations across every datastore, and emits a single reproducible bundle. Same input → byte-identical bundle.
$ sprintos compile stack.yaml
✓ resolve graph (12 nodes)
✓ validate schema
✓ plan migrations (3 datastores)
✓ snapshot mocks (7 endpoints)
✓ emit bundle → .sprint/build/
bundle-sha: a91f...c2e0Provision
Databases, messaging brokers and mock services start in dependency order. Migrations run in lockstep — SQL, shell, Python or Groovy — against the right datastore.
$ sprintos up --bundle .sprint/build
⠋ starting orders-db (postgres:16)…
⠋ starting events (kafka:3.7)…
⠋ starting payments-mock…
⠋ migrate orders-db (V1__init.sql)…
⠋ migrate orders-db (V2__seed.py)…
✓ stack ready (4.2s)Run
Your services connect against a fully wired stack — locally, in a Cloud Appliance VM, or on managed SaaS. Tear it down with one command and rebuild bit-for-bit tomorrow.
$ sprintos status
NAME TYPE STATUS URL
orders-db postgres healthy :5432
events kafka healthy :9092
payments mock healthy :8080/v1
─────────────────────────────────────────
bundle: a91f...c2e0 uptime: 00:04:12Reproducible. Portable. Boring on purpose.
Same bundle on your laptop, your CI, and your production-like preview environment.