From GitHub to AWS ECR: No More Manual Docker Pushes

Hey there,

If you've been manually building and pushing Docker images, you're likely tired of the repetitive command sequence every time you want to deploy.

Docker containers solve environment issues, but the deployment pipeline? That's where automation saves your sanity.

In Today's Issue: 

→ Hooking up GitHub Actions to push to AWS ECR
→ The essentials: secrets, IAM access, and pipeline structure
→ Common errors that derail your pipeline (and how to avoid them)

Let's dive in.

You're probably already using GitHub for your code and AWS for your infrastructure. Why not connect them directly? 

ECR provides secure image storage with built-in vulnerability scanning, and GitHub Actions handles automation without requiring an additional tool in your stack.

Put them together, and you get this:
Push to main. GitHub builds and tags your Docker image. It gets pushed to ECR. Done.

That’s the pipeline in action. But before it can run, there are two foundational pieces to put in place:

• An ECR repository: Your Docker image hub, created in the AWS Console.

• AWS IAM credentials: An IAM user with ECR permissions. You’ll use the access keys in your GitHub workflow.

With your ECR repo and credentials ready, it's time to connect the pieces. Add your AWS credentials to GitHub Secrets. Never hardcode them. GitHub Secrets keeps them encrypted and only accessible during workflow execution.

From there, you'll define the actual automation in a GitHub Actions workflow.

Create a workflow file at

.github/workflows/docker-image.yml 

This is where the pipeline lives. It handles the following: 

1. Checking out your code

2. Configuring AWS CLI access

3. Logging in to ECR

4. Building the image

5. Tagging it

6. Pushing it to the registry

Each step builds on the last. Once this is committed, any push to main triggers the whole process, and your image lands in ECR automatically.

Want to see the full workflow in action? Check out our step-by-step guide with code examples here.

Would it be DevOps if something didn’t break the first time? Here are the usual suspects to check when your pipeline throws a fit:

"Unable to locate credentials": Your GitHub Secrets names don't match what's referenced in the workflow file. Double-check for typos, because even small mistakes break authentication.

"Server misbehaving": This usually means your ECR repository name is incorrect. Verify your ECR_REPOSITORY secret matches exactly what's in AWS (these names are case-sensitive).

Permission denied: Your IAM user lacks proper ECR permissions. Attach the AmazonEC2ContainerRegistryFullAccess policy or create a custom policy with necessary ECR access rights.

Once your pipeline’s running, don’t stop there. These small tweaks now will save you hours later.

• Ditch "latest" for production: Use commit hashes or version numbers instead. Your future self will thank you when you need to roll back.

• Enable vulnerability scanning: AWS ECR scans for security issues automatically.

• Use smaller base images: Multi-stage builds can shrink image sizes by 10x. That’s faster deploys and lower storage costs.

• Protect your main branch: Require PR reviews before merging. This prevents broken deployments from reaching your pipeline.

• Set up failure alerts: Configure email or Slack notifications for workflow failures. Quick alerts help you catch and fix issues before they impact users.

The heavy lifting’s done. Every push to main triggers the same reliable process and keeps your team in sync.

Want to put this pipeline to work in your own repo? Check out the full setup with code and workflow details here.

What will you automate next?

And it’s a wrap!

See you Friday for the week’s news, upcoming events, and opportunities.

If you found this helpful, share this link with a colleague or fellow DevOps engineer.

Divine Odazie
Founder of EverythingDevOps