When we talk about multi-region deployments, one of the most common mistakes I see is building separate artifacts for each region. That not only increases build time but also complicates consistency.
So, when I was working on my pipeline, I decided to try a different approach
create one centralized build and reuse it across all three regional deployments.
The Initial Plan
My plan was simple:
- Build once in the CI stage.
- Upload the artifact using GitHub Actions’ default artifact storage.
- Reuse that artifact in multiple deployment jobs for three different regions.
Everything went well for the first few runs fast, efficient, and clean.
Until one day, my pipeline suddenly stopped with this error:
❌ “Artifact size limit exceeded. Please try again later.”
The Unexpected Limit
I retried after some time, thinking it might be a temporary glitch.
But soon I learned that GitHub imposes a timed quota for artifact storage.
Once your account hits that quota, you need to wait for the quota to reset before you can upload more artifacts.
That was a problem especially for continuous deployments where time and reliability matter.
The Workaround
To overcome this, I moved away from GitHub’s default artifact storage and used AWS S3 as my external storage layer.
Here’s the updated flow:
- The build job uploads the artifact to an S3 bucket.
- Each deployment job downloads it via a pre-signed URL.
- I applied a 7-day lifecycle policy on the bucket to automatically clean up old artifacts.
This way, I had:
✅ A centralized build accessible to all regions
✅ No dependency on GitHub’s quota system
✅ Automatic cleanup to control cost and clutter
The Takeaway
CI/CD isn’t just about writing YAML and triggering jobs.
It’s about designing pipelines that can scale not just in performance but also in resilience.
Sometimes, you only discover the right approach after hitting a limit or error message.
And that’s what makes the process truly DevOps-ish continuous learning, continuous improvement.
Top comments (0)