Set up a complete deploy pipeline ¶

This guide shows the recommended setup for deploying an application to several environments with the Nais CLI. It builds on Build and deploy with GitHub Actions, adding environment mixins for per-environment configuration and a split between code and manifest deploys.

For how Nais resolves the image, see Applying a manifest. For how mixins merge, see Environment mixins. For flags and file conventions, see the deploy reference.

Nais recommends keeping your manifests in a .nais/ directory: a base manifest plus one mixin per environment, and separate files for other resources.

Plaintext

The rest of this guide builds up each of these files.

Prerequisites ¶

Split configuration into a base manifest and mixins ¶

Keep shared and development configuration in a base manifest, and put each environment's overrides in a mixin file named .nais/app.<environment>.yaml. When you deploy with --environment <environment>, the CLI merges the matching mixin over the base.

.nais/app.yaml
.nais/app.dev-gcp.yaml
.nais/app.prod-gcp.yaml

Deploying with --environment prod-gcp merges app.prod-gcp.yaml over app.yaml, resulting in 2-4 replicas with higher resource requests.

Put per-environment values in map fields

Mixins override maps and scalars but concatenate lists. Keep per-environment values in map fields like resources and replicas. See merge rules for details.

Build once, deploy to every environment ¶

Build the image once, then deploy it to each environment with a mixin. The build job exposes the image as an output that every deploy step reuses.

.github/workflows/main.yml

Deploy manifest changes without rebuilding ¶

When you deploy without --set spec.image, the CLI keeps whichever image is currently running. Use this to deploy configuration changes without waiting for a build. Split the work into two workflows that trigger on different paths:

  • Code changes trigger a build and deploy.
  • Manifest changes trigger a deploy that reuses the running image.
.github/workflows/deploy-nais-resources.yml

To also stop the build-and-deploy workflow from running on manifest-only changes, add a matching paths-ignore to its on.push trigger.