Why use OIDC instead of access keys?

OIDC lets GitHub Actions assume an IAM role using short-lived credentials minted per run, so there are no long-lived AWS access keys stored in secrets to leak. It is AWS's recommended approach for CI and limits the blast radius of a compromise.

What is a rendered task definition?

An ECS task definition pins the exact image a service runs. The workflow takes your base task definition JSON, swaps in the freshly built image tag with the official render action, and registers it as a new revision before deploying.

How is the image tagged?

The workflow tags each image with the commit SHA so every deploy is traceable to an exact commit and rollbacks are unambiguous. It also pushes a latest tag for convenience.

Do I need a Dockerfile in my repo?

Yes. The build step runs docker build against a Dockerfile at the path you specify, defaulting to the repository root. The resulting image is what gets pushed to ECR and deployed.

Does this tool contact AWS?

No. It only assembles workflow YAML from your inputs in the browser. You add the IAM role ARN and any settings as GitHub secrets yourself, and nothing is uploaded by this page.

GitHub Actions Deploy to AWS ECS Workflow

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Deploying a container to AWS ECS Fargate from CI involves several precise steps: authenticating to ECR, building and tagging an image, pushing it, and registering a new task definition revision. This generator produces a complete GitHub Actions workflow that does all of that using OIDC role assumption, so no static AWS keys live in your repository.

How it works

The workflow uses the official AWS actions in a fixed order:

aws-actions/configure-aws-credentials assumes your IAM role via GitHub’s OIDC token — short-lived credentials, no stored keys.
aws-actions/amazon-ecr-login authenticates Docker to your private ECR registry.
docker build and docker push create and upload the image tagged with the commit SHA.
aws-actions/amazon-ecs-render-task-definition injects the new image into your task definition JSON.
aws-actions/amazon-ecs-deploy-task-definition registers the revision and updates the service, waiting for stability.

Tips and notes

Grant the IAM role only ecr:* on the repository plus the ECS and IAM PassRole permissions it needs — least privilege.
Tagging by commit SHA makes rollbacks trivial: re-deploy a prior task definition revision pointing at the old SHA.
Set wait-for-service-stability: true so the job fails if the new tasks never reach a healthy steady state.
Keep a base task definition JSON file in your repo so the render step has something to patch.