Skip to content

Runtime Environments

Runtime Environments are the instances of Arda’s Platform where products are run for development, testing, staging, or production purposes. Each Environment is the combination of an Infrastructure and one of its Partitions.

Note: The existing names follow the legacy naming convention in place at the time of their creation. New naming convention equivalents are listed below for reference.

Platform
Sandbox0001 (legacy → "Prod-amm-001" equivalent)
Sandbox0003 (legacy → "Sandbox-ui-001" equivalent)
Alpha001
prod
Alpha002
dev
stage
Root Services
NameStatusPurpose
Sandbox0001Active (deprecated path)Current production for Coda Pack integrations; monolithic CloudFormation + Helm deployment
Sandbox0003ActiveMinimal environment for UI development with AWS Amplify
Alpha001-prodIntegration testingLayered CDK + Helm; no Cognito auth; being superseded by Alpha002
Alpha002-devActive standardDevelopment environment with OAuth2/Cognito auth at API Gateway level
Alpha002-stagePlannedPre-production validation

Sandbox0001 will be decommissioned once Coda Packs and customers are migrated to an environment based on the Alpha001/Alpha002 configuration.

Alpha002 — Current Standard Configuration

Section titled “Alpha002 — Current Standard Configuration”

Alpha002 is the current standard. All new components should target this infrastructure.

Networking

  • VPC with subnets, route tables, internet gateway, NAT gateway, security groups
  • VPC Endpoint for Secrets Manager access
  • NLB (optional, deprecated for new deployments)

Computing

  • GitHub OIDC Provider
  • EKS Cluster with:
    • Cluster Role, General Pod Role, Secrets Access Role
    • Access entries for GitHub OIDC and admin users
    • Logs and log access policy
    • CoreDNS, Fargate profiles for add-ons
    • Load Balancer Controller
    • External Secrets Controller
    • Cluster Certificate Authority Data in SSM

Ingress

  • Route 53 Hosted Zones for <infrastructure>.app.arda.cards, <infrastructure>.io.arda.cards, <infrastructure>.api.arda.cards, <infrastructure>.auth.arda.cards
  • Route 53 records in the Root account routing capability domains to this Infrastructure
  • TLS certificates for each domain

Storage

  • Aurora Postgres Database Cluster with writer/reader instances, logs, monitoring dashboard, and master credentials in Secrets Manager

OAM / Authentication

  • Cognito User Pool with:
    • Post-Signup Lambda (auto-confirm users)
    • Password Reset Lambda (send recovery emails)
    • Resource Server, M2M Client, Web Client, User Pool Client applications
    • Custom attributes and scopes

Ingress

  • NLB with listeners and target groups (optional, coordinated with Infrastructure NLB)
  • API Gateway with Cognito Authorizer, VPC Link, default stage, custom domain, logging, and monitoring dashboard
  • CloudFront distribution for the API
  • EKS Ingress Controller and ALB bound to NLB target groups

Similar to Alpha002 with these differences:

  1. NLB is created by the Infrastructure layer (not Partition), limiting multi-partition routing
  2. No Cognito authentication; API Gateway has no authorizer

Components in this infrastructure must provide their own authentication (e.g., bearer token). Alpha001 will be decommissioned once Alpha002 integration testing completes.

Environments use CDK/CloudFormation. Outputs follow naming conventions:

TypeLogical ID patternExport Name pattern
Cross-repository (API)/.*_?API$//.*-API-.*/
Internal only/.*_?I$//.*-I-.*/
  1. In src/helm/read-cloudformation-values.cmd, map the export to a config key:

    readExport path.to.key.extras.some.myKey ${PURPOSE}-API-MyKey
  2. Define the config key in application.conf:

    extras {
    some {
    myKey = ""
    }
    }
  3. Include the key in src/helm/templates/configmap.yaml:

    path.to.key.extras.some.myKey={{ .Values.system.reference.item.extras.myKey | required "myKey" }}
  4. Add to lintValues in build.gradle.kts for lint validation.

  5. Run ./gradlew clean build then ./gradlew clean helmInstallToLocal to validate locally.