GitHub Actions and environment variables

[memeSnorter]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

I'm working with multiple environments (dev, staging, production) across several repos in a free organization. I know about environment-level secrets, but I'm running into a situation where I have to manually recreate the same environment configs for every single repository, which gets tedious fast.

Is there a recommended way to manage environment-specific variables and secrets more efficiently without duplicating them everywhere? I've seen some people mention reusable workflows but I'm not sure if that actually solves the secret-sharing part or just the workflow logic part.

Would love to know how others are structuring this, especially teams managing more than 5-10 repos. Any patterns or tools that have worked well for you?

[chemicoholic21]

Great question and something a lot of teams run into once they scale past a handful of repos!
So to clear up the reusable workflows part first, you're right that they solve the workflow logic duplication, but they don't magically share secrets for you. The secrets still need to exist in each repo or be explicitly passed into the reusable workflow using the secrets: inherit keyword, which at least reduces some of the manual wiring.
For actually managing environment configs across many repos without duplicating everything, the approach that works best really depends on whether your repos are public or private. If they're public, org-level secrets with environment scoping gets you pretty far. If they're private on a free plan, you're a bit more limited.
What I've seen work well for larger teams is leaning on an external secrets manager like HashiCorp Vault, AWS Secrets Manager, or even Doppler. You store everything in one place and each workflow just fetches what it needs at runtime based on the environment. This way you're not defining the same thing in 10 different repos, you're just referencing a central source of truth.
Another pattern that's underrated is using a dedicated internal "config repo" where you store non-sensitive environment variables as JSON or YAML files, and workflows pull from it using a checkout step. Obviously don't put actual secrets there, but for things like API endpoints, feature flags, or environment-specific config values it works surprisingly well.
If you're open to a bit of scripting, GitHub's CLI also lets you bulk-set secrets across repos using a simple loop, so at least the initial setup and updates become less painful even if the secrets still live separately per repo.
Honestly for teams above 5 repos, moving to an external secrets manager is worth the setup time. It pays off quickly!