Skip to main content

Production Deployment

Deployment follows a GitOps approach using Helm charts and Helmfile. You need to put your starter app into mistral-solutions repo to gain access to all the necessary secrets and CI workflows to be able to deploy to production.

Deployment Process Overview​

The overall process look like the following:

  1. Build Phase: a build-and-deploy GitHub workflow that you own builds Docker images from deployment/docker/docker-compose.yml definitions and pushes them to Azure Container Registry (ACR) at cdn-images.mistralai.com
  2. Configuration Phase: Application deployment is defined in /deployment/helm/production/starterapp/:
    • helmfile.yaml: Orchestrates chart deployments and versions
    • app.yaml.gotmpl: Values for the main application (frontend, backend, postgres, migrations)
    • worker.yaml.gotmpl: Values for the Temporal worker component
  3. Deployment Phase: Helmfile deploys Mistral OCI Helm charts (mistral-app-template and mistral-workflows-worker) with application-specific values, creating all necessary Kubernetes resources (deployments, services, ingress, secrets, service accounts). This phase is also triggered via CI (deploy workflow). It is trigerred on every open PR however it only actually deploy when the branch is merged on main.

Important Note: to merge on main (and deploy) you need approval from a code owner (Laurensc, Arthur-3 or Gustave at the time of writing).

Deployment Overiew Diagram​

Key Deployment Features​

  • Secrets Management: Environment-specific secrets (API keys, database credentials) injected via requiredEnv from CI/CD environment variables (usually set in GitHub secrets)
  • Service Account Integration: GKE Workload Identity binding for secure GCP resource access
  • Progressive Deployment: Worker deployed first (standalone mode) to create registry secrets, followed by main application
  • Authentication: APISIX handles OIDC authentication via Keycloak, with frontend getting automatic auth and backend supporting both OIDC and API key modes
  • Observability: OpenTelemetry enabled for distributed tracing across all components

Prerequisites​

  • Include your starterapp as a subfolder in the mistral-solutions repo.
  • Ensure the CI pass for your starterapp (in particular pre-commit checks)
  • Ensure your app deploy and work locally (see local deployment guide)

Production Deployment Steps​

1. Build and Push Docker Images​

The starter app ships with a build-and-deploy workflow ready for you to use. To make use of it copy {{project_name}}/deployment/.github/workflows/{{project_name}}-build-deploy.yml to .github/workflows/{{project_name}-build-deploy.yml.

The workflow will build and push the docker images to Azure Container Registery (ACR). Helm will then pull the images from ACR.

If your project requires special attention to build the images you can always customize the workflow.

Important Note: don't forget to adjust the workflow trigger to your desired branch to actually trigger it when you want it.

2. Write Helm Configuration​

The starter app ships with pre-configured helmfile and helm template values. You can find them in {{project_name}}/deployment/helm/production/{{project_name}}.

To make use of them you need to copy the {{project_name}}/deployment/helm/production/{{project_name}} folder to abraxas/deployment/helm/production/{{project_name}} in the mistral-solutions repo.

Don't forget to adjust app.yaml.gotmpl and worker.yaml.gotmpl to your needs. In particular you must set any additional environment variables / secrets you need.

At the very minimum, you need to set the images tags for all images that will be pulled for the deployment in both app.yaml.gotmpl and worker.yaml.gotmpl. (important do not use the latest tag it won't work). Tags look like 0.0.1-rc1-cee9778. You can find your tag in the output of the build-and-deploy workflow.

Secrets are usually stored as GitHub secrets on the repo. They are then added as env variable by the deploy workflow. Then helm create secrets out of those CI env variable coming from gh secrets. Finally you can request those secrets to be injected as env variable in your pods via the requiredEnv field in the helm values.

3. Deploy to Production​

Once you have followed the previous steps you can open a PR to merge your changes on main. Upon opening the PR the deploy workflow should be triggered.

Until your branch is actually merged on main your changes won't be reflected on the cluster. The deploy workflow only compute the diff of both terraform and your helm changes. The diff is displayed such that the code owners can review and approve it.

Upon approval you can merge your PR. Once merged on main, the deploy workflow will get triggered again this time actually performing the deployment on the cluster.