Node CI/CD to ECS with Terraform and GitHub Actions

Level:Intermediate

Time:2-3 hours

Cost:medium

Works locally:No

Cloud creds:Yes

Cleanup:No

Reviewed:2026-05-30

Validation:terraform -chdir=terraform fmt -check

Python Flask Docker ECS Terraform AWS GitHub Actions

Overview

ECS deployment tutorial; source appears Python despite Node-oriented title.

What You Will Build

Outcome Passing pipeline run plus scan/deploy evidence

Tools used Python, Flask, Docker, ECS, Terraform, AWS, GitHub Actions

Best fit Intermediate - 2-3 hours

Architecture Diagram

Student workstation Repository files CI/CD pipeline AWS account Validation proof

Prerequisites

• Install or review: Python, Flask, Docker, ECS, Terraform, AWS, GitHub Actions.
• Use your own cloud account credentials and keep them out of commits.
• This project expects cloud resources, so verify budget alerts and cleanup first.
• Open the safety guide before running commands that create infrastructure.

Credentials And Cost Warning

Cost and credential stance

Cost risk is medium. Cloud target: AWS. Cloud credentials needed: Yes. Always use your own account, never commit secrets, and confirm cleanup before creating paid infrastructure.

Step-By-Step Lab

Use this flow before you run commands:

1. Read the cost and credential warning above.
2. Review the validation, troubleshooting, cleanup, and portfolio proof sections below.
3. Follow the original project guide preserved near the bottom of this page.
4. Return to the validation and cleanup checks before you capture portfolio evidence.

Validation Checks

Run the project validation command before and after meaningful changes:

terraform -chdir=terraform fmt -check

Troubleshooting

• Run terraform -chdir=terraform fmt -check first so local tooling issues are visible early.
• If a command fails, check tool versions, working directory, and required environment variables.
• For cloud failures, confirm account identity, region, quotas, and least-privilege IAM.
• For pipeline failures, check repository secrets, runner permissions, and pinned action versions.

Cleanup

No dedicated cleanup command was detected in the project README. Treat this as a warning: before provisioning anything, write down the exact delete, destroy, or rollback steps for your environment.

Portfolio Proof

• Validation command output: terraform -chdir=terraform fmt -check
• Screenshot or terminal proof: Passing pipeline run plus scan/deploy evidence
• Notes explaining what changed, what failed, and how you fixed it
• Cleanup evidence, especially for cloud or Kubernetes resources

Original Project Guide

The original README content is preserved here for lab-specific commands and context. Headings are intentionally demoted so the page outline stays focused on the standard lab flow.

# 𝘾𝙄/𝘾𝘿 𝙬𝙞𝙩𝙝 𝙂𝙞𝙩𝙃𝙪𝙗 𝘼𝙘𝙩𝙞𝙤𝙣𝙨: 𝘿𝙚𝙥𝙡𝙤𝙮𝙞𝙣𝙜 𝙖 𝙣𝙤𝙙𝙚.𝙟𝙨 𝙖𝙥𝙥 𝙩𝙤 𝘼𝙢𝙖𝙯𝙤𝙣 𝙀𝙡𝙖𝙨𝙩𝙞𝙘 𝘾𝙤𝙣𝙩𝙖𝙞𝙣𝙚𝙧 𝙎𝙚𝙧𝙫𝙞𝙘𝙚 (𝙀𝘾𝙎) 𝙪𝙨𝙞𝙣𝙜 𝙏𝙚𝙧𝙧𝙖𝙛𝙤𝙧𝙢

In this blog post, I’ll demonstrate how to build, test & push docker images to AWS ECR (Elastic Container Registry) and run these images on AWS ECS (Elastic Container Service) using GitHub Actions.

The Goal

• Create a simple node site
• Create an docker image optimized for production and host it on ECR
• Use ECS to put this image online
• Use Terraform to create the AWS infrastructure
• The source files are hosted on github
• Use Github actions to automatically update the site online after a commit
• A new docker image will be automatically generated and hosted on ECR
• This new image will be automatically deployed on ECS

🛡️ 2026 DevSecOps Enhancements (What You Will Learn)

This repository has been upgraded to enforce strict 2026 DevSecOps guardrails:

1. Deprecation of Long-Lived Credentials: While the legacy tutorial references storing AWS_ACCESS_KEY_ID in GitHub Secrets, our modernized pipeline utilizes OpenID Connect (OIDC) authentication. This provides ephemeral, short-lived tokens to GitHub Actions, virtually eliminating the risk of permanent credential leakage.
2. ECS Non-Root Execution: The ECS Task Definition generated by Terraform has been hardened. The Node.js container is explicitly configured to execute as a restricted node user, severely limiting the blast radius if the container codebase is compromised.

Prerequisites

Before creating GitHub Actions workflow yaml file, we need to complete the following steps:-

1. Setup AWS CLI with appropriate credentials.
2. Create an AWS ECR repository to store our docker images.
3. Create an AWS ECS task definition, cluster, and service.

Getting Started

First of all, we need to build the application in our local environment. Here is my demo application link.

Now , we will go back to ECS in our AWS console. We need to copy the json file from our “Task Definition” and Paste it into our local environment under .aws directory and and then push it to our github repository.

GitHub Secretes Configuration

We need to store the AWS_ACCESS_KEY_ID & AWS_SECRET_ACCESS_KEY into the secrets of our repository on GitHub. Navigate to the “Settings” section in our GitHub repository and locate the “Secrets” section on the left-hand side. By clicking the “new repository secret” we are going to add these two secrets.

Configuring the GitHub Actions workflow

Now, it’s time to configure the GitHub Actions. GitHub Actions uses YAML syntax to define the workflow. This workflow need to be stored as a separate YAML file in our code repository, in a directory named “. github/workflows”

Before getting started with the github actions configuration I’ll try to explain a little bit about workflow and job. A workflow is a configurable automated process made up of one or more jobs that will be executed sequentially. A job consists of several steps of instructions that perform in a remote server to be executed. In this project, the workflow actions are supposed to test and build the image of our application using Dockerfile and push that image into the AWS ECR to run it on an ECS environment.

Let’s create a ci/cd pipeline workflow to test,build and push our node.js application to deploy in our AWS ECS environment. We will create a configuration file named “main.yaml” (you can choose a different name according to your preference) under “.github/workflows” in our local environment.

First of all we set a workflow name and need to trigger this workflow, whenever there is a pull or push on the main branch. Now, we need to specify the environment variable for our ECS service that we have created.

Note: Ensure that you provide your own values for all the variables in the env key of the workflow

Here in the jobs we have created a job called “test”. We also set a build matrix with “ubuntu-latest” remote environment/Runner that will test jobs under different node versions. Under “steps” we set tasks that we need to run under the “test” job. We have created another job called “deploy”, where the “deploy” job only runs when the “test” job gets passed. Finally, The following steps are performed in the workflow file, if test job gets passed and deploy job started for running:

1. Checks-out our repository under GitHub Workspace, so our workflow can access it.
2. Configure the AWS credentials.
3. Login to AWS ECR.
4. Build, Tag, and push the image to AWS ECR.
5. Update the AWS ECS service with a new task definition.

Deployment & Result

Once we completed our workflow, we will push it to our github repository. We can check out the “actions” tab and see that a new action has started which is indicated by the yellow color indicator. Moreover, we can see the build logs where each tab shows the current task and on expanding each tab you can see its logs.

Now we have to wait until the whole process is completely finished. If we get some errors, we follow through the details for every step, so that we can solve the error.

Having automated deployments to ECS is quite easy with Github actions. Yet, it’s quite powerful as it allows us to deploy automatically every time there is a change in our code.

Yuppp, we’re done here! Feel free to reach out to me if you have any queries or doubts.

Thanks for your time!

Source Files On GitHub

Use the guide first.

The full learning flow stays on this page. Open GitHub only when a step asks you to inspect code, fork the lab, or download source assets.

Read safety guide Open project source