Back to notes
• 3 min read

Git Sync on an Existing Stack

There are two ways to wire a stack to Sync from Git, and this series uses both. Worth knowing which is which before the deploys start.

Attach to an Existing Stack

You already did this once. In post 3 you created the role stack by uploading infra.yaml by hand, then connected Git Sync to it after the fact. That is the existing-stack flow: the stack is already there, so you attach Git Sync through its Git sync tab rather than at create time.

The steps, which you ran on the role in post 3:

  1. Open the stack in CloudFormation and click the Git sync tab, then Connect.
  2. Select the CodeConnection from post 2.
  3. Enter the repository, branch (main), and the deployment file path (deployment-file.yaml).
  4. Select the IAM role Git Sync assumes (CloudFormationGitSyncRole from post 3).

Reach for this whenever you have bootstrapped a stack manually and want to stop updating it by hand.

One stack stays manual: the connection from post 2. It is a one-time bootstrap, created and authorized once, with nothing left to redeploy, so it has no deployment file and never gets a Git Sync config. The Git Sync role deliberately can’t manage connections anyway.

Create a New Stack with Git Sync

The other flow creates the stack and wires Git Sync in a single step, through Create stack > Sync from Git. You never deploy it by hand at all. Post 6 does this with the certificate stack, and every certificate and site stack after it follows the same path.

Same Result

Both flows end in the same place: a push to the tracked branch triggers a deployment, no console clicks. The only difference is the starting point, a stack that already exists versus one created fresh.

One caution for either flow: Git Sync deploys whatever lands on the tracked branch using the role you select. The role repo is the sharpest case, since its role can edit its own permissions. Protect main and keep push access as tight as you would keep IAM access in the console.