> ## Documentation Index > Fetch the complete documentation index at: https://playbook.smedleygroup.com/llms.txt > Use this file to discover all available pages before exploring further. # Architecture and Deployment Pipeline > The TypeScript CDK app, the GitHub sourced pipeline, the four stacks and why they are separated, and how a change reaches production. This page covers how SG-Infra is structured as code, and how a change gets from a commit to live infrastructure. ![SG-Infra deployed infrastructure. Box colour shows the deploying stack; dashed grey is owned by TalentIdPipeline-Infra-CDK.](https://mintcdn.com/smedley_group/J4Qb1kGrTQEJOjVR/images/software/developer/estate/infra/sg-infra/architecture.png?fit=max\&auto=format\&n=J4Qb1kGrTQEJOjVR\&q=85\&s=627b3c62877baf4d3d3faf9ad1cbcc57) > [!NOTE] > > The diagram source is the draw\.io file at `images/software/developer/estate/infra/sg-infra/architecture.drawio`. To change the diagram, edit that source in draw\.io, re-export it as PNG to `architecture.png` in the same folder, and commit both. ## Overview SG-Infra is a single TypeScript AWS CDK application. Like the legacy repo it does not deploy resources directly: it defines a self-mutating CodePipeline that deploys everything. Unlike the legacy repo it is written in TypeScript (the team standard), is sourced from GitHub, and splits the infrastructure into four separate stacks so that concerns, and especially the data volume, are isolated from each other. | Setting | Value | | - | - | | AWS account | `338232497876` | | Region | `eu-west-2` (London) | | Pipeline | `SgInfraPipeline` | | Source | GitHub `Smedley-Group-Advanced-Technology/SG-Infra`, branch `prod` | | IaC | TypeScript AWS CDK (`aws-cdk-lib` 2.215.0) | ## High-Level Structure * The CDK app (`bin/cdk_build.ts`) contains the pipeline stack (`SgInfraPipelineStack`). * The pipeline stack defines the self-mutating CodePipeline (`SgInfraPipeline`) and points it at the GitHub repository. * The pipeline runs one stage, named `prod`, which deploys four stacks: `SgInfraSecurityStack`, `SgInfraBackupStack`, `SgInfraVolumeStack` and `SgInfraMongoInstanceStack`. * Every stack is tagged with `Project` `FMP`. ## The CI/CD Pipeline * **Source:** the `prod` branch of the GitHub repository, connected through an AWS CodeConnections connection. This is the modern, GitHub based approach, and a key difference from the legacy repo, which is sourced from CodeCommit. * **Synth step:** changes into the `CdkBuild` directory, runs `npm install`, then `npx cdk synth`. * **Self-mutation** is enabled, so the pipeline updates itself before deploying the stacks. * Assets are published one at a time rather than in parallel. * A dedicated S3 artifact bucket (`sg-infra-pipeline-artifacts`) holds pipeline artifacts. ## The Four Stacks and Why They Are Separated The single `prod` stage deploys four stacks. Splitting them is deliberate, and is one of the main improvements over the legacy single grouping: * **`SgInfraSecurityStack`** looks up the shared VPC, and creates the security groups, the EC2 key pair, the MongoDB connection secret, and the SSM configuration that consumers read. * **`SgInfraBackupStack`** creates the versioned S3 backup bucket. * **`SgInfraVolumeStack`** creates the persistent EBS data volume. Keeping the volume in its own stack means the database storage has an independent lifecycle and is not torn down when the instance is replaced. * **`SgInfraMongoInstanceStack`** creates the EC2 instance, attaches the data volume, and provisions MongoDB. It receives the VPC, security group, key pair, secret, data volume and backup bucket from the other stacks. CDK wires the dependencies automatically from these cross-stack references, so the stacks deploy in the correct order (security, volume and backup before the instance). ## How a Change Reaches Production **1. Merge to prod** A change is merged to the `prod` branch on GitHub. **2. Pipeline triggers** The CodeConnections connection triggers the `SgInfraPipeline` pipeline. **3. Synth** The Synth step installs dependencies and runs `cdk synth`. **4. Self-mutate** The pipeline self-mutates, applying any change to the pipeline itself. **5. Deploy** The `prod` stage deploys the four stacks in dependency order. > [!WARNING] > > As with the legacy repo, there is no manual approval gate. A merge to `prod` flows straight through to production infrastructure. Because this currently underpins Fleet Management Platform, changes should still be made with care. ## Why It Is Built This Way * TypeScript CDK and GitHub source bring SG-Infra onto the team standard tooling, which is the main reason it exists as the go-forward pattern. * Separate stacks isolate the blast radius within the system. The volume in particular is isolated so that rebuilding or replacing the instance does not put the data at risk. * The pattern is still a single account, single region, single environment deployment. As with the legacy repo, dev and production are separate databases on the one instance rather than separate environments. For now those are just `FMP_DEV` and `FMP_PROD`, since only Fleet Management Platform uses SG-Infra so far; as more systems adopt it the instance will host many databases. ## Key Files | File | Role | | - | - | | `CdkBuild/bin/cdk_build.ts` | The app entry point | | `CdkBuild/lib/sg_infra_pipeline_stack.ts` | The self-mutating CodePipeline and its GitHub source | | `CdkBuild/lib/sg_infra_cdk_stage.ts` | The `prod` stage that instantiates the four stacks and wires dependencies | | `CdkBuild/lib/sg_infra_utils.ts` | Shared constants (account, region, the GitHub connection ARN) and IAM policy helpers | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.