GitHub Actions Overview

Quant Cloud provides a suite of official GitHub Actions to automate your deployment workflows. These actions work together to build, deploy and operate containerised applications.

Available Actions

Action	Purpose	Latest release	Commit SHA
Init	Validate access, log Docker in to the registry, detect the environment	v4.0.1	1bc52dca113ea1cb2f3d7dcb0edbc7859d76afaf
Compose	Validate and translate docker-compose.yml	v4.0.0	3a06db471e3364db3e4691fd522b9c37346d0a19
Environment	Create, update or delete environments	v4.0.0	936fe16373f3169fa15b61a9117ffa87b3996855
Environment Vars	Manage environment variables	v1.0.2	ce1ea37c9f7e9169c1c70df35ae3fe6f1111e2c9
Sync	Copy a database or files between environments	v4.0.0	aeb054d52e2067ac7eb6694c07df2c4cde262c5f
Backup	Create, list, download and delete backups	v4.4.2	9c46be7346ab2ec78f7dd5e0b0795ce2eff3eca2
State	Redeploy, stop or start an environment	v4.0.1	b1b75af5d772bb295bc067f225a7bb3a952bd7a1

The repositories are quantcdn/quant-cloud-<name>-action (for example quant-cloud-init-action). The separate quant-cloud-ecr-action is superseded by the Init Action. For static sites, use quantcdn/deploy-action and quantcdn/purge-action.

Image architecture and build runners

The image you push to your application’s internal registry must include the architecture selected for the Quant Cloud environment:

Quant Cloud architecture	Docker build platform
X86_64	linux/amd64
ARM64	linux/arm64

For customer workflows, set the GitHub Actions repository variable BUILD_PLATFORM to the required platform. New template workflows default to linux/amd64 on ubuntu-latest. RUNNER_TYPE chooses the build runner; it does not choose the image architecture.

ARM64 builds with QEMU can be slow

Building linux/arm64 on an x86_64 runner uses QEMU emulation and can take much longer, especially when compiling dependencies or compressing images. If you use ARM64 on Quant Cloud, use your own native ARM64 runner for regular builds where possible. Set RUNNER_TYPE to that runner’s label, for example quant-arm64, and BUILD_PLATFORM to linux/arm64. The runner needs Docker and Buildx. Install QEMU only when building for another architecture or for multiple architectures.

Quant CI runners give you native arm64 and x64 runners that Quant hosts, so you do not have to run your own.

For example, a single-architecture customer workflow can use:

jobs:
  build:
    runs-on: ${{ vars.RUNNER_TYPE || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v5
      - uses: docker/setup-qemu-action@v3
        if: ${{ contains(vars.BUILD_PLATFORM, ',') || (runner.arch == 'X64' && (vars.BUILD_PLATFORM || 'linux/amd64') != 'linux/amd64') || (runner.arch == 'ARM64' && (vars.BUILD_PLATFORM || 'linux/amd64') != 'linux/arm64') }}
      - uses: docker/setup-buildx-action@v4
      # Initialize Quant Cloud to authenticate to the internal registry, then build:
      - uses: docker/build-push-action@v7
        with:
          context: .
          platforms: ${{ vars.BUILD_PLATFORM || 'linux/amd64' }}
          push: true
          tags: YOUR_INTERNAL_REGISTRY/YOUR_ORG/YOUR_APP:app-latest

Workflows that resolve BUILD_PLATFORMS can use different architectures for different environments in the same repository. This variable is a JSON object keyed by the Quant Cloud environment name, for example {"production":"linux/amd64","staging":"linux/arm64"}. The environment entry takes precedence over BUILD_PLATFORM. Older workflow copies need the platform-selection and conditional QEMU steps added before these variables take effect. When changing an environment’s architecture, build and push the new variant before deploying it. A single-architecture image built earlier does not gain another variant when you change the environment setting.

Published Quant template images support both linux/amd64 and linux/arm64. Pre-built deployments use those published images; customer repositories build their own images into their application’s internal registry. To publish your own multi-architecture image, use platforms: linux/amd64,linux/arm64 and verify both variants in its image index:

docker buildx imagetools inspect YOUR_INTERNAL_REGISTRY/YOUR_ORG/YOUR_APP:app-latest

See Docker’s multi-platform build guidance for emulation and native builder options.

Typical Workflow Pattern

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      # 1. Initialize - validate access, log in to the registry, detect the environment
      - uses: quantcdn/quant-cloud-init-action@v4
        id: init
        with:
          quant_organization: ${{ secrets.QUANT_ORGANIZATION }}
          quant_api_key: ${{ secrets.QUANT_API_KEY }}
          base_url: ${{ vars.QUANT_BASE_URL || 'https://dashboard.quantcdn.io' }}

      # 2. Build and push images (Docker is already logged in by init).
      #    The tag starts with the compose service name, e.g. app-latest.

      # 3. Translate the compose file
      - uses: quantcdn/quant-cloud-compose-action@v4
        id: compose
        with:
          api_key: ${{ secrets.QUANT_API_KEY }}
          organization: ${{ secrets.QUANT_ORGANIZATION }}
          compose_file: docker-compose.yml
          image_suffix: ${{ steps.init.outputs.image_suffix_clean }}
          base_url: ${{ vars.QUANT_BASE_URL || 'https://dashboard.quantcdn.io' }}

      # 4. Create or update the environment, then redeploy an existing one (State Action)
      - uses: quantcdn/quant-cloud-environment-action@v4
        with:
          api_key: ${{ secrets.QUANT_API_KEY }}
          organization: ${{ secrets.QUANT_ORGANIZATION }}
          app_name: ${{ steps.init.outputs.quant_application }}
          environment_name: ${{ steps.init.outputs.environment_name }}
          operation: ${{ steps.init.outputs.environment_exists == 'true' && 'update' || 'create' }}
          compose_spec: ${{ steps.compose.outputs.translated_compose }}
          base_url: ${{ vars.QUANT_BASE_URL || 'https://dashboard.quantcdn.io' }}

The actions create environments, not applications. Create the application first in the dashboard or with the API.

QuantCDN and QuantGov

Every Quant Cloud action takes a base_url input. It defaults to QuantCDN. For QuantGov, set it on every Quant Cloud step:

Platform	base_url
QuantCDN	https://dashboard.quantcdn.io (default)
QuantGov	https://dash.quantgov.cloud

The v4 actions also accept the value with /api/v3 (https://dash.quantgov.cloud/api/v3). The Environment Vars Action (v1.0.2) accepts only the host without /api/v3; see its page. The API key belongs to one platform.

Secrets and variables

Name	Store as	Value
QUANT_API_KEY	Secret	An API token from your dashboard profile (API Tokens)
QUANT_ORGANIZATION	Secret	Your organisation machine name
QUANT_APPLICATION	Variable	Your application name (the workflows default to the repository name)
QUANT_BASE_URL	Variable	QuantGov only: https://dash.quantgov.cloud/api/v3 (or the host alone)

Tokens are secrets: GitHub masks them in logs and does not give them to workflows that run for pull requests from forks. Names and URLs are not sensitive; as variables they stay readable in the job log. For production, keep the secrets in a GitHub environment with protection rules.

Pin actions by commit SHA

A tag can move: @v4 follows each new 4.x release, and the owner of a repository can move any tag. A commit SHA cannot change. To control exactly what runs, pin the full SHA and keep the version in a comment:

- uses: quantcdn/quant-cloud-init-action@1bc52dca113ea1cb2f3d7dcb0edbc7859d76afaf # v4.0.1

Dependabot (package-ecosystem: github-actions in .github/dependabot.yml) opens pull requests that update the SHA and the comment together. To find the newest tag and its commit SHA: git ls-remote --tags --sort=-v:refname https://github.com/quantcdn/<action> 'v*.*.*' | head -2, then gh api repos/quantcdn/<action>/commits/<tag> --jq .sha.

A successful run does not mean the release is live

The actions ask the platform to deploy and finish when the request is accepted. They do not wait for the new containers to start or pass health checks. After a deploy, check the environment: qc env list --org <org> --app <app> shows running and desired task counts, qc env logs shows container output, and the dashboard Deployments tab shows each deployment’s status and error. To make a workflow wait, see the State Action.

Other CI systems

The qc CLI logs in through a browser (OAuth) and has no option for an unattended token login, so do not use it in CI jobs. In GitLab CI, Bitbucket Pipelines and other systems, call the platform API with curl and an API token, as the actions do:

API=https://dashboard.quantcdn.io/api/v3        # QuantGov: https://dash.quantgov.cloud/api/v3
AUTH="Authorization: Bearer $QUANT_API_KEY"     # from the CI system's masked secrets

# Registry login (short-lived credentials: endpoint, username, password)
CREDS=$(curl -fsS -H "$AUTH" "$API/organizations/$ORG/applications/ecr-login")
REGISTRY=$(printf '%s' "$CREDS" | jq -r .endpoint | sed -E 's#^https?://##')
printf '%s' "$CREDS" | jq -r .password |
  docker login "$REGISTRY" --username "$(printf '%s' "$CREDS" | jq -r .username)" --password-stdin

# Build and push <registry>/<organisation>/<application>:<service>-<suffix>
docker buildx build --platform linux/arm64 -t "$REGISTRY/$ORG/$APP:app-latest" --push .

# Redeploy the environment
curl -fsS -X PUT -H "$AUTH" -H "Content-Type: application/json" \
  -d '{"action": "redeploy"}' \
  "$API/organizations/$ORG/applications/$APP/environments/$ENV_NAME/state"

For static sites in other CI systems, use the quant CLI: see Using the Content CLI in CI/CD pipelines.

Common Use Cases

• Production deployment from main: the Init Action maps main to production. See the workflows in the Quant templates.
• Pull request environments: see Environment Action.
• Database sync from production to staging: see Sync Action.
• Scheduled backups with retention: see Backup Action.

Best Practices

1. Always start with the Init Action: it handles registry login and environment detection.
2. Use image_suffix_clean from init in image tags, after the compose service name.
3. Read the compose translation warnings printed by the Compose Action.
4. Protect production with GitHub environment protection rules.
5. Clean up preview environments when pull requests close.
6. Check each deploy as described above; a green run is not proof.

Next Steps

• Init Action Reference
• Quant templates for complete workflows