Application Development Platform

Previous release: v1.2.6 

Focus: v1.3.0 turns the ITGix Application Development Platform (ADP) from a command-line installer into a portal-driven product. Until now the typical journey was to fill in a form, download a YAML file and run idpinstall.py on your own machine. With this release the new ADP control-plane UI can provision an environment directly from the browser, giving customers a SaaS-like experience while the installer keeps doing the actual work behind the scenes. Backstage moves to the centre of the platform as the Internal Developer Portal: it is wired into ADP-CX, ships self-service software templates with dynamic variables, and no longer assumes it is running on AWS.

Under the hood the installer gains a complete GCP provisioning path alongside AWS, selected with --cloud aws|gcp, and a first-class destroy command that replaces the standalone cleanup.sh. Both template repositories move to v1.3.0 with major infrastructure upgrades: EKS module 21, AWS provider 6, Kubernetes 1.35 by default, configurable and much larger VPC subnets, EFS for ReadWriteMany storage, serverless ElastiCache, and a cloud-agnostic GitOps layer that renders ingress, certificates and secret stores per cloud.

• Provision from the UI portal. The new ADP control plane offers two workflows. Generate & Download keeps the familiar model: configure the environment in the UI, download the YAML and run the installer locally. Direct Cloud Provisioning connects the customer's cloud credentials and provisions the environment without leaving the browser. The portal also covers destroy, cluster and workspace lifecycle management, saved configurations with provisioning history, and an embedded ArgoCD view.
• Backstage as the IDP front door. Backstage moves to v1.2.7, is integrated with ADP-CX, and gains self-service software templates driven by dynamic variables, an opt-in guest login, and cloud-agnostic ingress, registry and secret handling so the same deployment works on AWS and GCP.
• Dual cloud. --cloud aws|gcp selects a complete install and destroy path per cloud. GCP uses a GCS state bucket, GKE, Cloud DNS and Artifact Registry, and the GitOps layer renders cloud-aware ingress and service-account annotations. AWS remains the default, so existing invocations are unchanged.
• destroy is now a first-class command. The 440-line cleanup.sh is folded into the installer. Before terraform destroy runs, the installer disables ArgoCD auto-sync and deletes all ingresses so that cloud load balancers are released by their controllers instead of being orphaned.
• Larger, configurable VPC subnets. New AWS environments get /21 private and /23 public subnets instead of the hardcoded /26, removing the most common cause of pod scheduling failures on busy clusters. Existing environments keep their layout automatically.

The customer-facing configuration UI has been rebuilt from the ground up and promoted from a config generator into a control plane for the whole platform.

• New control-plane UI. The previous config generator front end is replaced by a new application built on Next.js 16, TypeScript, Radix UI and Tailwind 4, with NextAuth v5 for authentication, organised as a Turborepo monorepo.
• Two provisioning workflows. Generate & Download produces the environment YAML exactly as before, for customers who want to run the installer from their own workstation or CI. Direct Cloud Provisioning runs the installer for you, so a customer can go from an empty cloud account to a running platform entirely from the portal.
• Direct cloud provisioning from the browser. A container-based provisioning runner executes the installer server-side. The run can happen either in a container started by the portal or from the ADP environment itself using the credentials the customer supplies.
• Destroy from the UI, together with buttons to delete individual clusters and workspaces, so the full lifecycle of an environment can be managed without a terminal.
• ArgoCD embedded in the portal. The ArgoCD UI is embedded via iframe, so the delivery state of the platform services and applications is visible from the same screen without a context switch.
• Backstage integration through the CX. The bootstrap flow now links straight into the developer portal, so the environment you just provisioned is one click away from its Backstage instance.
• Bootstrap UI fixes and a reworked how-to screen. The onboarding screen now walks through the credentials and prerequisites required for each workflow, and a set of layout and validation issues reported against the first bootstrap UI have been fixed.
• Template versions kept current in the UI. The portal offers the latest environment and GitOps template refs rather than the pinned older ones, so a freshly generated config always targets a supported template version.
• AWS onboarding automation with OIDC-bootstrapped cloud identities. The portal provisions against the customer account through a federated identity instead of long-lived static access keys, which removes the need to hand over or rotate secret keys.
• Persisted configurations and provisioning history. Saved configurations can be reloaded, listed per project and looked up by the CLI, so an environment definition is entered once and reused for updates, re-provisioning or destroy instead of being retyped each time.
• Guided multi-step forms. Forms are built with React Hook Form and Zod validation so mistakes are caught before a config is generated, flow diagrams built with XY Flow explain what will be created, and the copy and field descriptions have been refreshed throughout.

Backstage is now the front door of the platform, and this release removes the AWS-only assumptions that previously stood in the way of running it elsewhere.

• Backstage image default bumped from v1.2.3 to v1.2.7.
• Cloud-agnostic Backstage deployment. The ingress class and ingress annotations are resolved per cloud by the GitOps helpers, so the same chart produces an ALB ingress on AWS and a GCE ingress on GCP. The container registry defaults to ECR on AWS and to the project's Artifact Registry on GCP, taken from the artifact_registry_repository_urls.platform Terraform output.
• enable_guest_login feature toggle. Guest authentication used to be forced on whenever the environment was not development. It is now off by default and opt-in from the environment YAML, which closes an unintended anonymous access path on shared environments.
• CLOUD_REGION replaces AWS_REGION as the scaffolder secret, so software templates that need to know the region work unchanged on both clouds.
• Dynamic variables in Backstage scaffolder templates (adp-backstage-scaffold). Templates are driven by a variable list that renders into multi-step forms, output a link to the resulting GitLab merge request or GitHub pull request, and support optional ingress, image-pull-secret templating and a configurable listen port. New "Phoenix" templates orchestrate version upgrades across several applications at once.
• Backstage credentials sourced from External Secrets. The GitHub and GitLab tokens and the Backstage auth secret are read from the cloud secret manager through an ExternalSecret, with the ClusterSecretStore selected per cloud (secretstore-aws or secretstore-gcp) instead of being hardwired to AWS Secrets Manager.
• Backstage URL surfaced at the end of an installer run, next to the ArgoCD details, so the portal address does not have to be looked up in the cluster.

The installer grows from a single-purpose provisioning script into a small CLI with explicit subcommands, a real teardown path, and safer handling of customer-owned files.

• install and destroy subcommands with --cloud aws|gcp (--platform is accepted as an alias). AWS is the default, and a bare ./idpinstall.py --awsprofile ... still behaves as install, so existing scripts and pipelines keep working without changes.

  ./idpinstall.py install --awsprofile myaws --config-file config/foo.yml --dry-run ./idpinstall.py install --cloud gcp --config-file config/gcp-foo.yml ./idpinstall.py destroy --awsprofile myaws --config-file config/foo.yml --dry-run ./idpinstall.py destroy --cloud gcp --config-file config/gcp-foo.yml --skip-k8s-cleanup

• cleanup.sh integrated into idpinstall.py destroy. The Python implementation replaces the shell script and follows the same stage and logging conventions as install, including the live status panel and per-step log files. cleanup.sh remains only as a thin backwards-compatible wrapper that translates the old flags into a destroy invocation.

• Graceful teardown before terraform destroy. The installer first disables ArgoCD auto-sync on the app-of-apps so that ArgoCD does not recreate resources while they are being removed, then deletes all ingresses so that the ALB or GCE controllers release the cloud load balancers. Without this step the load balancers and their network interfaces would survive the Terraform run and block subnet and VPC deletion.

• New destroy flags.

  Flag	Effect
  --dry-run	Preview the destroy actions without changing anything.
  --skip-k8s-cleanup	Skip the Kubernetes-side cleanup, for clusters that are already unreachable, and destroy only Terraform-managed resources.
  --cleanup-repos	Remove the generated content from the destination repositories after the destroy.
  --clean-env-files-only	Remove only the environment- and region-specific subtrees from the destination repositories, leaving other environments in the same repos untouched.

• Terraform variables are driven by the template's own variables.tf. The installer parses the environment template's variable declarations into a registry and emits a tfvar for every YAML key that matches a declared variable. Any Terraform variable the template exposes can therefore be overridden straight from the environment YAML without an installer change, and dictionary values are deep-merged onto the variable's declared default so a partial override such as a single add-on version does not wipe the rest of the map. Keys that do not match a declared variable are dropped.

• Custom ArgoCD values are no longer overwritten. Generated content is written to values.generated.yaml, while a user-owned values.yaml is created once and then left alone. Hand-written ArgoCD overrides now survive --update-gitops and --update-all re-runs.

• Environment-template compatibility gate. The installer validates the configured env_template_repo_branch up front and reports the supported range, instead of failing deep inside Terraform on a variable that the pinned template does not know. Standard tags and -ai tags have separate minimum versions, and GCP accepts its own list of supported refs. --allow-unsupported-env-template bypasses the check when you know what you are doing.

• HTTPS fallback on clone. When cloning a template repository over SSH fails, for example on a host without a GitHub SSH key, the installer retries the clone over HTTPS before giving up.

• Destination-repository push fixes. Pushes rejected because of conflicts in the destination repository are handled correctly, and GitOps templates that no longer exist in the template repo are pruned from the destination repo on update rather than left behind.

• Kube-context selection fixed so the installer reliably talks to the cluster it just created, and the installer's startup dependencies were refactored.

• Run UI no longer wraps output text on wide terminals, so long log lines and URLs stay readable.

• --update-infra-facts-only regenerates just infra-facts.yaml in the destination repos, for the case where only Terraform outputs or configuration values changed and nothing else in the GitOps repo should be touched.

GCP is now a fully supported target for both install and destroy, implemented as a parallel flow next to AWS so that neither cloud's behaviour is compromised by the other.

• New GCP install and destroy path. The Terraform state lives in a GCS bucket named with the same {project}-{environment}-{region}-idp-state convention as on AWS. The GKE cluster context is obtained through gke-gcloud-auth-plugin, and Terraform variables and backend configuration are generated for GCP. The project is taken from the config file or overridden with --gcpproject, and credentials come from a service-account key file passed with --gcp-credentials-file or from the gcloud Application Default Credentials when it is omitted.
• config/gcp-template.yml is the new reference configuration for GCP environments, covering GKE, Cloud SQL, Memorystore, Cloud DNS, Artifact Registry and GCS. It is exercised by the test suite alongside the AWS template.
• Cloud-aware GitOps rendering. Ingress annotation maps are merged in the order ingress_annotations -> <cloud>_ingress_annotations -> <app>_ingress_annotations, and service-account maps follow the same order with service_account_annotations, <cloud>_service_account_annotations and <app>_service_account_annotations. The most specific map wins when a key is repeated. On AWS this produces ALB annotations and ingressClassName: alb; on GCP it produces the gce class, a GKE ManagedCertificate and a FrontendConfig HTTPS redirect. Supported ingress app prefixes are argocd, backstage, policy_reporter, grafana, alertmanager, prometheus and devlake; supported service-account prefixes are external_dns and external_secrets. GKE managed certificates and HTTPS redirects can be switched off globally with gcp_ingress_managed_certificates_enabled: false and gcp_ingress_https_redirect_enabled: false.
• infra-facts.yaml carries the cloud. The file now contains a cloud key and a whitelist of structured annotation maps, so per-cloud ingress and service-account configuration survives from the environment YAML into the Helm values of the GitOps layer.
• README documents AWS and GCP side by side, including the prerequisites, authentication steps, install and destroy commands for each cloud.

Kubernetes & compute

• EKS module upgraded 20.31.6 -> 21.23.0, the AWS provider moved to >= 6.42, < 7.0, and the Terraform required_version is now >= 1.5.7, < 2.0. Both the module and the provider bump are major versions; see the upgrade notes below.
• Default Kubernetes version raised from 1.34 to 1.35, with matching add-on defaults: kube-proxy v1.35.3-eksbuild.21, VPC CNI v1.22.4-eksbuild.3, CoreDNS v1.13.2-eksbuild.21 and EBS CSI v1.65.0-eksbuild.1. addons_versions is no longer a required variable. Every field is optional with a default, so an environment YAML can pin a single add-on and inherit the rest, and the map gains efs_csi and resolve_conflicts_on_create.
• Standard and EKS Auto Mode flows merged into one template, gated by enable_eks_auto_mode, so there is one code path to maintain and one set of variables to document.
• karpenter_allowed_instance_types constrains which instance types Karpenter may provision, for cost control and for accounts with instance-family restrictions.
• Add-on bootstrap ordering fixed, so add-ons that depend on each other are created in the right sequence. IRSA moved to the new iam-role-for-service-accounts-eks module structure with static policy names, and the VPC CNI role gains ec2:DescribeSubnets, which the newer CNI needs.

Storage & data

• EFS support via enable_efs_csi. The template provisions an EFS file system and the matching CSI driver, which enables ReadWriteMany volumes for workloads that need shared storage across nodes. Everything is tunable and optional:

  Parameter	Purpose
  efs_encrypted, efs_kms_key_id	Encryption at rest, with the AWS-managed key unless a KMS key is given.
  efs_performance_mode	generalPurpose or maxIO.
  efs_throughput_mode, efs_provisioned_throughput_in_mibps	bursting, provisioned or elastic, with the provisioned rate when applicable.
  efs_transition_to_ia, efs_transition_to_archive, efs_transition_to_primary_storage_class	Lifecycle transitions to Infrequent Access and Archive, and back on access.
  efs_backup_policy_enabled	Enable AWS Backup for the file system.

• ElastiCache serverless (Redis/Valkey). redis_serverless_enabled switches from a provisioned replication group to a serverless cache, with variables for the engine version, snapshot window, usage limits and snapshot restore. This is the recommended option for environments whose cache load is bursty or small.

• RDS. rds_db_instance_parameters allows parameter-group overrides from the environment YAML, and rds_failover_priority sets a custom failover ordering across instances. The RDS module moves to v1.0.9.

Networking & security

• Configurable VPC subnets with larger defaults. The private and public subnets were hardcoded to /26, which gives roughly 60 usable IPs per availability zone. Because the EKS VPC CNI assigns a VPC address to every pod, such a subnet is exhausted by a modest number of workloads and pods end up stuck in Pending. Each tier is now sized with vpc_private_subnets, vpc_public_subnets and vpc_database_subnets, either as newbits and offsets relative to the VPC CIDR or as explicit cidrs. On a /16 VPC the new defaults are:

  Tier	Before	Now
  private	/26 x3	10.x.0.0/21, 10.x.8.0/21, 10.x.16.0/21
  public	/26 x3	10.x.28.0/23, 10.x.30.0/23, 10.x.32.0/23
  database	10.x.24.0/24, 10.x.25.0/24, 10.x.26.0/24	unchanged

  Overlapping or undersized layouts are reported at plan time rather than failing during apply.

• VPC module upgraded 5.5.x -> 6.7.2. No resources are renamed, added or replaced by this bump.

• WAF. waf_ip_prefix_sets and waf_ip_prefix_rules manage multiple IP prefix lists and the rules that reference them, replacing the single ip_whitelist_prefixes variable, and waf_ip_whitelist_forwarded_ip_config allows whitelisting based on the forwarded client IP behind a proxy or CDN. The WAF module moves to v8.

• ACM. acm_create_route53_validation_records skips the creation of Route 53 validation records when the hosted zone lives in another account, and a new option skips certificate verification entirely for environments without a hosted zone.

Operational

• aws-apn-id partnership tag applied to all resources, which is required for AWS Partner Network attribution of the workloads ADP provisions.
• All Terraform module sources switched from SSH to HTTPS. Provisioning no longer requires an SSH key or agent on the host for module fetching, which simplifies CI runners and the browser-driven provisioning runner.

Cloud-agnostic GitOps

• The infra-services chart helpers render the ingress class, ingress annotations and service-account annotations per cloud through infra-services.ingressClassName and infra-services.ingressAnnotations. A new gcp-ingress-resources.yaml template produces the GKE ManagedCertificate and FrontendConfig HTTPS-redirect objects that GCE ingresses need.
• The External Secrets ClusterSecretStore and its service account are templated per cloud, replacing the AWS-only manifests, so secrets are pulled from Secrets Manager on AWS and from Secret Manager on GCP with the same chart.

New optional services

• CloudNativePG operator, cert-manager with a ClusterIssuer, and the barman-cloud backup plugin for CloudNativePG, enabled with enable_cloudnative_pg, enable_cert_manager and enable_barman_cloud_plugin. All three are off by default, so existing environments are not changed by the upgrade.
• EFS storage class with enable_efs_csi and efs_file_system_id, using Access Point dynamic provisioning so that each PersistentVolumeClaim gets its own access point on the shared file system. This is the cluster-side half of the ReadWriteMany feature introduced in the Terraform template.

Observability & security

• Trivy Grafana dashboard and PrometheusRules. Vulnerability scan results are now visible in Grafana and can raise alerts. The alert rules moved into the Prometheus values, and the dashboards are only rendered when the Grafana stack is enabled.
• kube-prometheus-stack chart 0.47.10 -> 0.57.7. The storage specification and retention (60 days, 50Gi on gp3) moved out of the ArgoCD Application into the chart values where they can be overridden per environment. The Prometheus and Alertmanager ingresses are no longer created by default, reducing the exposed surface to Grafana only.
• Grafana host URL configurable with grafana_ingress_host, plus fixes to the Grafana ingress.
• Fluent Bit chart bumped, the Kyverno sync failure caused by CRD migration fixed, and policy-reporter updated.

Platform services

• external-dns supports multiple managed DNS domains, so one cluster can publish records into several zones.
• Karpenter. Managed instance-type allowlist wired to the Terraform variable, the aws-apn-id tag applied to the EC2 nodes it launches, and an optional blockDeviceMappings override with a default 20Gi encrypted gp3 data volume.
• ADP billing/DevOps agent updated with slimmer container builds and tuned resource requests.
• DevLake secret handling and values updated.

Read this section fully before upgrading an existing environment. The items are ordered roughly by how much attention they need.

• Template refs pinned to v1.3.0. config/template.yml and config/gcp-template.yml now point at adp-tf-envtempl-standard@v1.3.0, adp-k8s-templ-argoinfrasvcs@v1.3.0 and adp-k8s-templ-argoappsdemo@v1.3.0. config/gcp-template.yml moves to the same GitOps ref, the first one that is GCP-capable, and pins the sample applications repository instead of tracking main. Bump the three *_template_repo_branch keys in your environment configs to v1.3.0.

• EKS module 20 -> 21 and AWS provider 5 -> 6 are major upgrades. Always run

  ./idpinstall.py install --awsprofile <profile> --config-file <env.yml> --update-infra --dry-run

  and read the Terraform plan before applying to an existing environment. Expect in-place updates on the cluster and IAM resources; anything marked for replacement deserves a second look.

• Default Kubernetes version is now 1.35 (was 1.34), with add-on versions defaulted to match. Pin eks_cluster_version in the environment YAML if you are not ready to move, and remember that addons_versions no longer has to be supplied at all. If you previously pinned it in full, you can now reduce it to only the add-ons you actually want to override.

• VPC subnets are larger for new environments and unchanged for existing ones. The template reads the subnets of an already provisioned VPC back from AWS and reuses them, so upgrading plans no subnet changes. Every plan now prints a warning listing the layout being kept, which is expected and not an error.

  To adopt the larger ranges on an existing environment set force_subnet_resize: true. This re-creates the private and public subnets and with them the EKS managed node groups (all nodes are rolled) and the EFS mount targets, while the VPC, the EKS cluster itself, the NAT gateway Elastic IPs, RDS and ElastiCache/Valkey are kept. Delete the Kubernetes-managed load balancers first, because their network interfaces are not managed by Terraform and block the deletion of the old subnets, and expect workload downtime while the node groups are re-created. Re-create the load-balancer services and ingresses afterwards.

  The database subnets are deliberately excluded and sit behind a separate force_database_subnet_resize, because moving them re-creates the DB subnet group and therefore the RDS cluster and the ElastiCache/Valkey replication groups. Use it only with a restore plan at hand. The full procedure and the custom newbits / offsets sizing options are in the README.

• Backstage guest login is now off by default. If your users relied on guest access, set enable_guest_login: true in the environment YAML before upgrading, otherwise they will be asked to sign in through the configured identity provider.

• WAF IP whitelisting changed shape. ip_whitelist_prefixes is replaced by waf_ip_prefix_sets and waf_ip_prefix_rules. Translate the existing prefix list into one set and one rule that references it before applying, or the whitelist rule will be removed.

• Prometheus and Alertmanager ingresses are no longer created by default. Re-enable them explicitly if you were reaching them directly rather than through Grafana.

• Terraform module sources are now HTTPS. Hosts that relied on an SSH agent for module fetching need HTTPS access to github.com instead. Template repositories are still cloned over SSH, with the new HTTPS fallback when that fails.

• cleanup.sh is deprecated in favour of ./idpinstall.py destroy. The wrapper still works and translates the old flags, but the new flags (--skip-k8s-cleanup, --cleanup-repos, --clean-env-files-only) are only available on the subcommand.

• ArgoCD values split into generated and user-owned files. After the first --update-gitops run on v1.3.0 you will find values.generated.yaml next to values.yaml under helm/argo-cd/values/{environment}/{region}/. Move any manual edits you previously made to the generated file into values.yaml, which is never overwritten again.

• Annotation maps must be whitelisted. Any new *_ingress_annotations or *_service_account_annotations key added to an environment YAML must be listed in IDPSTATE.structured_config_vars, or it will be stripped out of infra-facts.yaml and never reach the Helm values.