From Sam G on 2016/04/30 19:30:46 +0000
This would be useful for sharing code signing certificates, AWS keys, etc across multiple apps.
Copied from original feature request: http://bitrise.uservoice.com/forums/235233-general/suggestions/13680282-share-global-environment-variables-and-files
Share global environment variables and files / Organization level environment (and secret) variables
From Callum Taylor on 2016/09/22 10:27:38 +0000
+1 We have lots of apps that have different keystores, but all stored in one file, rather than having to upload it multiple times and risk them going out of sync, would be nice to just have one place where we can update it
+1 here.
Any update on this since September?
No update yet, please vote on this #feature-request to bump its priority!
so was this implemented?
No, not yet. Planned but no ETA yet.
Would be very nice 
If you can share some details about what kind of env vars / secrets you’d like to share between apps that would help us a lot in refining this feature! We have our list, but having as much context as possible always helps in designing the features 
Mostly it’s like global information for all the apps.
- API token slack
- API token phraseapp
- Apple account logins because the itunes connect step doesn’t use the info like auto-provision step does.
- Maybe reusable team IDs (enterprise team is always same ID)
It would be handy if you have ‘organisation’ shared envs and ‘user’ shared envs.
Because Bitrise requires to have 1 apple login with access to all the teams of different clients.
But we are planning to create a ‘bitrise user’ for every client. So we can still use different apple logins.
But the client has some shared envs as well.
- Fabric token & secret
- apple login & password
- …
This way we can store all information of 1 client in one bitrise account and the client has multiple apps.
So we share all the envs across all the apps from that client.
I hope this gives you some information of how we would use it.
Friendly regards,
Seppe
5 Likes
Definitely, thanks for the infos @seppe_r!
Some things that would be nice to have shared across apps:
- Github Enterprise API URL
- Github access tokens
- AppStoreConnect credentials (formerly iTunesConnect)
- Slack webhook.
- Code signing identities (.p12)
3 Likes
We build a large number of apps for customers and it would be super useful to be able to have our own wildcard dev certs and variables available globally so that we don’t need to manually add and update them within each customers app in Bitrise. That way each customer app is just setup with their own certs and variables but if we need to create an internal build for testing we can just trigger a workflow that uses our global certs/variables instead
1 Like
+1 would help us a lot
it’s been almost 4 years now and it’s the 3rd most voted for feature… is there any chance this is ever going to be implemented?
Am currently setting up +20 different apps under our org and many need the same environment variable(s).
Hello @jastley
I will discuss this feature request with the product and update them.
Thanks
Chaitanya
1 Like
+1
Any updates in 4 years?
Hello,
We still have this on our list, but unfortunately, we cannot provide an update or ETA. We have lots of feature requests, as well as exciting new features, that we are working on and have to re-evaluate and prioritize. This can cause dates to shift and status to change.
Thanks!
Hi Everyone!
We are currently in the concept creation phase of this feature, and we would like to ask for your help. We have a couple questions unanswered so we’d like to speak to a couple of people who requested this feature to understand the details better and to ask your feedback regarding our concept.
If you would like to help the product team and jump in a 30 minutes discussion with them, you can book an appointment here:
That’d would be very helpful!
You can load Secrets dynamically during a build now from a Secret Vault and redact them from the logs using the new --sensitive flag when using Envman
envman add --key MY_SECERT_ENV_KEY --value 'this is a secret value' --sensitive