Install & infrastructure

How Cardinal ships.

For: developers and operators

Cardinal's two halves deploy independently — the static front end and the function-hosted API — and every shipped change is smoke-probed against the live site and attested on the audit spine. The chain is the changelog: there is no separate record of what shipped that could drift from reality.

FE + API deploy independently Smoke-probed live Attested on the spine

The per-change ship loop

Front end

  • Build the SPA
  • Publish the built assets to the Static Web App
  • Routing and auth come from the app's static configuration

Back end

  • Build and bundle the API
  • Publish to the Function App (Flex Consumption)
  • The Static Web App reaches it through a linked backend
Then: probe, attest, record. Each deploy is smoke-probed against the live site to confirm it took; the Steward attests the shipped change on the audit spine; and the change is recorded. If the probe fails, the change isn't considered shipped.

Why ship this way

Tying every deploy to a live probe and an attestation means the question "what is running right now, and is it verified?" always has an answer you can trust — the same audit chain that records engagement decisions also records what shipped. Independence of the two halves means a front-end fix doesn't wait on the API, and vice versa.

The resources it deploys onto → · Provision them first →