Skip to content
Kesita Kesita Kesita docs

Releases

Kesita can build and validate release artifacts, but it does not yet have a complete staging-to-production deployment command. Validation is not deployment authorization.

Release flow

Section titled “Release flow”
flowchart LR
    Source[Source SHA] --> Build[Build 10 images]
    Build --> Digest[OCI digests, SBOM<br/>and provenance]
    Digest --> Manifest[Release manifest]
    Manifest --> Verify[Metadata and<br/>signature verification]
    Verify -. future protected workflow .-> Stage[Deploy staging]
    Stage -. acceptance evidence .-> Production[Promote production]

The ten images are the app, public site, docs, Product API, Legal Core API, product worker, corpus worker, document parser, and two database migrators. Each deployable owns its Dockerfile and adjacent release.json.

Terminal window
./bin/kesita release catalog
./bin/kesita release --help

The catalog validates build definitions. Release validation checks manifest structure and pins. Signature verification checks publisher identity and exact content binding. None of these commands applies infrastructure or grants production approval.

CI boundary

Section titled “CI boundary”
flowchart TB
    CI[Continuous integration] --> Checks[Type, lint, unit and selected Hermit checks]
    CI --> Images[OCI candidates for linux/amd64]
    CI --> Terraform[Format, init, validate<br/>and mocked tests]
    Images -. no publication authority .-> Registry[(Private ACR)]
    Terraform -. no apply .-> Azure[Azure resources]

Azure definitions live under infra/terraform/azure/. Staging and production have separate foundation and runtime roots. Runtime consumes foundation outputs, pinned image digests, and versioned secret references. Mocked Terraform tests do not prove live permissions, networking, TLS, backups, or recovery.

Before a real deployment exists

Section titled “Before a real deployment exists”
  • Keep image digests, source SHA, evidence, and signatures bound to one release manifest.
  • Use maintenance mode only as a revision gate; a controller must still drain workers, run migrators, verify readiness, and activate the release.
  • Preserve worker revisions while durable DBOS executions can replay against them.
  • Verify private networking, ingress, workload identity, database roles, restore paths, and rollback in the target environment.
  • Do not run terraform apply from this guide alone.

The executable command contract belongs to CLI help and CI workflows. Update this page only when the release guarantees change.