Environment variables are something every application needs today. Big or small, sooner or later everyone has to deal with them.
People often say: “This is easy. Just store them in a secure place.”
And yes, everyone knows the best practices by heart.
But for almost six months, I was completely lost trying to find the right solution.
My Problem
From my previous article, you may know that I deploy microservices using AWS ECS.
Each service has a task definition, where environment variables are mapped to Parameter Store and Secrets Manager, two AWS services designed to store configuration and secrets securely.
For storing environment variables, everything works quite well.
But for managing them in a clear and simple way, so that team members can easily add, remove, or modify variables, things become much harder.
To do that properly, you need some knowledge about:
cloud infrastructure
IAM permissions
rollback responsibilities when something goes wrong
So I had an idea.
I created a separate project dedicated to environment variables for all services, including both normal variables and secrets. The idea was simple: if someone wants to change something, they only need to update it there.
I also set up Infrastructure as Code with Terraform for the project. Deploying variables to Parameter Store and Secrets Manager became very easy.
But then another problem appeared.
The Headache
My team uses GitHub (not self-hosted). All repositories are private.
But as everyone knows:
Pushing environment variables directly to GitHub is almost like committing suicide.
Every second, there are automated tools scanning GitHub repositories for exposed secrets—even private ones.
So the project stayed on my local machine.
But that obviously wasn’t a real solution.
What happens if someone else wants to add or modify variables? Should they just copy the project from my computer?
At a company where I previously worked, things were much simpler.
They hosted their own GitLab registry, everything was private, and they simply pushed the environment variable project there and connected it to a pipeline.
Very straightforward.
The Solution (Not Very Surprising)
You might not believe it, but I spent almost half a year thinking about this problem.
I considered many ideas.
For example:
encrypting environment variables before pushing them to GitHub
decrypting them during deployment
But honestly, those solutions were too complex and inefficient.
My goal is always the same:
solutions should be as simple as possible.
Developers already suffer enough. There’s no need to make a simple problem complicated—because once the system becomes complex, maintenance becomes harder and mistakes become more likely.
And usually, no one understands that logic except the person who designed it.
The solution I finally used was actually something I had thought about before, but the conditions at the time didn’t allow it.
AWS CodeCommit.
In many ways, CodeCommit works just like GitHub. All standard Git operations work the same way.
However, when I first considered using it, AWS had temporarily disabled the creation of new repositories for CodeCommit (around 2024, if I remember correctly). So that idea had to be abandoned.
Time passed, and I still hadn’t found a good solution.
Then one day, while scrolling Facebook during AWS re:Invent 2025, I saw the news that AWS had reopened the ability to create new repositories in CodeCommit.
So I started implementing the solution immediately.
(What if they disabled it again? Haha.)
The Implementation
CodeCommit repositories are protected inside the AWS account, with multiple layers of security.
I also set up a CI/CD pipeline for this project using:
AWS CodeBuild
AWS CodePipeline
And sorry AWS… but honestly, I’m not a big fan of these CI/CD services.
They feel too complicated for solving problems that other tools handle much more simply.
But that’s okay.
If it works, it works. 😄
Conclusion
Everything now runs the way I wanted.
But finding this solution definitely took too much time and sweat.
And honestly, the architecture still isn’t perfect because the source code is now split across different places (GitHub and CodeCommit).
Hopefully there will be better solutions for managing environment variables in the future.
If you have a better approach, please share it with me. I’d love to learn. 🙂
(If you enjoy these kinds of engineering stories, you can subscribe to receive the next ones.)