Hello everyone, I’ve been reading a lot here but this is my first post. I’m part of a small team responsible for our customer support platform, and we’re currently running our CI/CD on CircleCI. Our main workflow is deploying container updates to an ECS Fargate service, and we’re a team of five engineers.
Lately, we’ve been feeling the pinch of CircleCI’s pricing model as our build minutes add up. We’re exploring a move to GitHub Actions since our code is already on GitHub and it seems like it could simplify things. I’m nervous about a migration disrupting our deployment process, though.
I’m hoping to hear from anyone who has made a similar switch for a comparable stack. Specifically, I’m wondering about a few things. How did you handle translating your existing pipelines, especially the ECS deployment steps? Was migrating secrets and context from CircleCI to GitHub Secrets relatively straightforward? And most importantly, how long did the actual transition take from your first experimental workflow to fully turning off the old CircleCI pipelines?
Our setup isn’t overly complex, but reliability is critical for our customer-facing tools. Any step-by-step insights or pain points you encountered would be incredibly helpful.
I'm Brian, lead engineer at a 40-person SaaS shop running Fargate workloads. We migrated from CircleCI to Actions a year ago for the same reason.
**Real pricing:** CircleCI's cost scales with minutes, which becomes punitive. With five engineers, your CircleCI bill is likely $180-250/month if you're hitting that 15-20k minute range. GitHub Actions gives you 3000 free minutes/month on their default runner, which covered 80% of our workload. Our bill went from ~$220 to $60/month.
**Migration effort:** Translating your existing `.circleci/config.yml` to a GitHub workflow YAML is a one-to-one mechanical task for Fargate deploys. The hardest part was moving the ECR login step and the `ecs-deploy` command pattern. It took me one afternoon per workflow. The entire transition for three services was about 1.5 engineer-weeks.
**Where it breaks:** The main limitation is matrix builds. If you run a lot of parallel jobs across many container combos, Actions' concurrency limits on the free tier will throttle you. CircleCI's parallelism config was simpler for that specific use case. We don't do that.
**Vendor lock-in:** This is where Actions wins clearly. Your CI config lives in your repo, not on a vendor's server. You can run the exact same Actions workflows via self-hosted runners if you ever leave GitHub. With CircleCI, you're rewriting everything.
I'd pick GitHub Actions for your team's use case. The migration is straightforward for a simple Fargate deploy, and the cost savings are immediate and substantial. If your workflows are strictly linear ECR build -> ECS deploy, make the switch.
Trust but verify.