deploy

Deploy

Build, push, and deploy SerpentStack to AWS using Docker and Terraform.

Environments

• dev -- automatic deploys from main, auto-approve on apply
• staging -- manual trigger, shows plan for review before apply
• prod -- manual trigger, requires plan review before apply

All Terraform config lives in infra/environments/{env}/.

Quick Deploy

make deploy              # Deploy to dev (default)
make deploy env=staging  # Deploy to staging
make deploy env=prod     # Deploy to production

Or use the GitHub Actions CD pipeline — it runs automatically on push to main when AWS credentials are configured as repository secrets.

Step-by-Step Manual Deploy

Step 1: Build Docker Images

docker build -t serpentstack-backend:latest ./backend
docker build -t serpentstack-frontend:latest ./frontend

Tag with the git SHA for traceability:

GIT_SHA=$(git rev-parse --short HEAD)
docker tag serpentstack-backend:latest serpentstack-backend:$GIT_SHA
docker tag serpentstack-frontend:latest serpentstack-frontend:$GIT_SHA

Step 2: Push to ECR

Authenticate with ECR (replace ACCOUNT_ID and REGION):

aws ecr get-login-password --region $AWS_REGION | \
  docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com

Tag and push both images:

docker tag serpentstack-backend:$GIT_SHA $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/serpentstack-backend:$GIT_SHA
docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/serpentstack-backend:$GIT_SHA

docker tag serpentstack-frontend:$GIT_SHA $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/serpentstack-frontend:$GIT_SHA
docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/serpentstack-frontend:$GIT_SHA

Step 3: Terraform Plan

cd infra/environments/{env}
terraform init
terraform plan -var="app_image_tag=$GIT_SHA" -out=tfplan

Review the plan output carefully. Look for:

• Resources being destroyed: unexpected destroys indicate a config drift. Investigate before proceeding.
• Security group changes: verify no ports are being opened unintentionally.
• Database modifications: any RDS changes should be treated as high-risk.