Back to site
Platform

Deployment

Container images built per commit by CI, verified as a complete set before the commit counts as a release, pulled by the target which refuses to start a partial one - with each service reporting the commit it was built from

The topology

A container per service, composed: the control plane, the query engine, the extract executor, the ledger service, the process service, the collaboration server, PostgreSQL, Redis, S3-compatible object storage, the identity services, the orchestration engine and its workers, and a reverse proxy in front.

The same composition runs in the cloud and inside a customer perimeter. What differs is who operates it and which model providers are configured.

A release is a commit

The rule that everything else follows from: a release is a commit, not a set of images that happen to be current.

Stage What happens
Push to main CI builds one image per service
Tagging Each image is tagged with the commit. That tag is immutable.
Verification A final job confirms every image in the set exists. A partial build is not a release.
Deploy The target pulls that commit's set and refuses to start if any image for it is missing
Confirmation Services report the commit they were built from, so the fleet can be checked for agreement

There is also a moving convenience tag per service. It is informational and production never uses it: a per-service moving tag cannot say that the fleet agrees on one commit, which is the only question worth asking during an incident.

Build and run are separate descriptions

The base composition describes how each service is built; a deployment overlay describes what to run - published images, not local builds. Neither leaks into the other, so a developer's local rebuild and a production deploy cannot silently change each other's meaning.

Migrations

Database migrations run on their own path at service start, not as a deploy step. A deploy that spans several commits carries whatever migrations accumulated between them, which is worth checking before a large jump.

Verifying what is running

Because every service reports its build commit, "what is production running" is a query, not a comparison of image timestamps. A periodic check compares the reporting services against an expected commit.

On-prem

The same path: a customer pulls a verified image set on their own schedule. Air-gapped installations take the set as an archive. Model providers are configured locally, so an on-prem deployment can run entirely without outbound network access - see Privacy and on-prem for the hardware.

  • Platform - the service topology and where the scaling levers are.
  • Versions and the built-in git - the same rule one level up: an application's release is a commit too.
  • Licensing - what an installation is entitled to run.
  • Audit - what a deployed system records.