Skip to main content

Overview

This guide walks you through deploying SGP in an Azure cloud subscription using the SGP Azure Terraform modules. SGP Azure infrastructure is defined by terraform modules managed by Scale.

Prerequisites

  • Access to an Azure subscription with sufficient permissions to create resources (Contributor + User Access Administrator roles, or equivalent)
  • The following tools installed:
  • The following from Scale:
    • The SGP Azure Infrastructure Terraform modules (azure-terraform/infra)
    • A workspace_id and registration_secret unique to your deployment
  • A new application configured in your identity provider to authenticate to the SGP platform (SAML or OIDC) (optional)
  • A custom domain for your deployment (optional)

Installation

Step 1: Build Configuration

Configuration is split across three files. This allows you to reuse the same configuration for multiple environments.

File 1: main.tfvars.json

This file selects which configuration to load. Edit it to point at your customer and environment before running Terraform.

File 2: config/<domain_code>/default.yaml

Customer-wide baseline settings that apply to all environments unless overridden. This file is the right place for stable policy and posture decisions: tenant identity, tagging standards, and security baselines for Key Vault, PostgreSQL, Redis, Storage, and other services.

File 3: config/<domain_code>/<location>/<environment_type>.yaml

Environment-specific configuration. This is where you set everything that differs per environment: resource names, subscription, CIDRs, feature flags, node pool sizing, and bootstrapping state.
Naming constraints for Azure resources:
  • Key Vault names: 3–24 alphanumeric characters and hyphens, globally unique
  • Storage Account names: 3–24 lowercase letters and numbers only (no hyphens), globally unique
  • PostgreSQL and Redis names: globally unique within Azure
  • All names must remain stable after first apply — many Azure resources cannot be renamed

Step 2: Provision Infrastructure via Terraform

Navigate to the infra directory and initialize:
Review and apply the plan using the main.tfvars.json file you configured in the previous step:
If the Datadog monitoring integration is enabled in your YAML, pass the API key via environment variable rather than committing it to file:
This step may take significant time (30–60 minutes) due to resource creation dependencies, particularly the AKS cluster and PostgreSQL Flexible Server.

Step 3: Bootstrap the Cluster

The Azure infrastructure automatically bootstraps SGP System Manager via an Azure Deployment Script. When bootstrapping.enabled: true is set in your configuration, Terraform provisions an Azure Container Instance that:
  1. Installs Flux CD on the AKS cluster (using Azure Managed Flux if use_managed_flux: true)
  2. Applies the System Manager HelmRepository and HelmRelease Flux CRDs
  3. Waits for System Manager to reconcile
Monitor bootstrap progress in the Azure Portal under Deployment Scripts in your resource group, or check System Manager logs after bootstrap:

Accessing the Private AKS Cluster

Because the AKS cluster is private by default, you must access it from within the provisioned VNet. Two options are provided: Option A: From the jump host VM (via Azure Bastion) The Bastion host and jump host VM are provisioned when bastion.create: true. Connect via the Azure Portal (Bastion blade) or using the helper script:
Option B: Using az aks command invoke When aks.run_command_enabled: true, you can run kubectl commands without VPN access:

Step 4: Configure DNS

After terraform apply completes, retrieve the Front Door endpoint hostname:
Configure a CNAME record in your DNS provider pointing your deployment_url to the Front Door endpoint (the azurefd.net hostname from the output above).
If using Azure DNS (the DNS zone is managed by Terraform when frontdoor.create: true), CNAME records are created automatically. Verify with:

Step 5: Verify the Deployment

Wait for all services to be ready:
System Manager continuously reconciles the desired state. The bootstrapping.desiredState value in your environment YAML is written to a secret in Azure Key Vault during terraform apply, and System Manager reads from that secret at runtime. If a HelmRelease shows Ready=False, check its events:

Step 6: Configure Identity Provider

SAML Configuration

Set authType: "SAML" in your environment YAML, then configure your Identity Provider with:
  • Service Entity ID: https://auth.<deployment_url>
  • Redirect URI: https://auth.<deployment_url>/dashboard/org/saml/callback
Update the is-saml-secret secret in Key Vault (or via System Manager GUI):

OIDC Configuration

Set authType: "OIDC" in your environment YAML, then configure your Identity Provider with:
  • Redirect URI: https://auth.<deployment_url>/dashboard/org/oidc/callback
Update the is-oidc-secret secret in Key Vault (or via System Manager GUI):
After modifying an identity secret, restart System Manager to apply the changes:

Accessing the Platform

If all goes smoothly, you should be able to navigate to the SGP platform at https://<workspace_id>.workspace.egp.scale.com (or your custom domain) and authenticate via the configured identity provider.