Recommended Handling of Private Keys for OSS GitHub Apps


I am currently working on an open-source GitHub App, and am having some trouble figuring out a good pattern for allowing others to contribute.

Specifically, I want to let others try running the app if they need to test things - and this requires a private key. I’m under the impression committing a private key file, even one for an app labeled “testing”, would not be a good idea from a security standpoint. However, the only other pattern I can come up with to allow others to run the app is to document the GitHub App configuration and require they setup an equivalent configuration on their account, generate their own key, and put it in some pre-defined location. That seems like a lot to ask of someone, and I’m leary of adding an obstacles or barriers to anyone contributing to my project.

Has anyone figured out a good pattern for this? Is there a recommendation documented somewhere I am missing? My primary goals with any pattern in this space are security and minimum “barrier to contribution”.

Thanks for any advice!


Hey Romeara,

I’ve run into this myself recently. Deploying an own GitHub up is not easy at this point. I know that the Probot community ( is looking into ways to make it easier.

In case you build your app on probot, I’ve created a form for people to quickly deploy a GitHub app from a GitHub repository to Glitch: - just follow instructions. I know it’s not perfect, but maybe it helps a bit?


Thanks for pointing me in that direction! The app I’m currently working on unfortunately isn’t built on Probot, but knowing that is there is useful!


So I’ve been thinking about what I’d consider “ideal” in this case, as a way to clarify what I’m seeing as an area for improvement in tooling for OSS GitHub Apps. Disclaimer, I’m fully aware the following might be a little beyond what is likely to happen - mostly hoping to get other people’s thoughts, and I usually find it easier to start from something, even if it’s far-fetched.

I’d like to see something that allows a repository to document and define the GitHub App settings the application is meant to operate with in a file (basically, lay out the settings you enter when you add a “GitHub App” in your user or organization settings). This file could live in the “.github” folder, just as the current “CODEOWNERS” file may now.

When a potential contributor forks the repository, GitHub could, as part of the forking process, give the user an option to setup a GitHub App in their account from the settings defined in the file. This would setup the app (set to only be installable on the forking user’s account), and potentially give them an option to download a copy of the private key.

This way, the barrier to contribution to OSS GitHub Apps is reduced - it’s automatically setup for contributing users in a consistent manner. It is also more secure - each “App” for a contributor is different, and is only installable on their account - and the owner of the repository isn’t tempted to ever commit a private key to the repo for users to test with.

So, just to try to summarize, the main thing I’m trying to solve is the current choice between security and low contribution effort. I’d love to see what people like or dislike about the suggestion above, and see if it helps someone come up with something that is better in the short term, and/or doesn’t ask for such significant effort on GitHub’s part.

Also, as a side note - I don’t think there are REST APIs exposed which would allow the above to be done by a GitHub App. If someone knows otherwise, I’d be more than happy to take a crack at writing a GitHub App to streamline development of GitHub Apps :slight_smile: