Data Security and Handling

We consider it a great responsibility that you have trusted us with your GitHub repository/data, and we take it very seriously. Although installing an App may take just a few clicks, we think it’s important that you know what happens to your repository data once you install Renovate.

The content in this document does not replace or override anything in our Privacy Policy. We provide it for your “peace of mind” and with the hope of receiving feedback that may enable us to improve security and data handling even further.

If you have any suggestions or questions about our security, please contact us at immediately. Please do not disclose any security concerns in a public forum.

GitHub App Private Key

The most important consideration for GitHub App security is the Private Key used to access installations. This key is metaphorically the “key to the kingdom” and is essentially the only thing anybody needs to gain access to all repositories on which the Renovate App has been installed, so we have handled it with great caution:

  • The key is not saved to disk anywhere. We do not keep a backup of it on any device, thumbdrive, or password manager.
  • The key is saved in one location - as an AWS EC2 Parameter Store “Secure String”
  • The EC2 instance we run Renovate on gains access to this Secure String using its IAM Role permissions
  • The private key is not exposed/saved to “env” at any time
  • There exists no generated AWS “Access Key” that has permissions to either (a) read from EC2 Parameter Store, or (b) create IAM users or roles with permissions to access the secure string, or (c) create a new EC2 instance that could gain access
  • When the Renovate App runs and decrypts the Private Key, it is stored in memory only as long as necessary to retrieve temporary tokens for each installation, and it is never written to any log

App Ownership

We have chosen to assign ownership of the app to an otherwise unused account “keylocation” (named after our registered company Key Location Pte Ltd). This account is used for nothing else - so essentially is never logged in - and protected by 2 Factor Authentication. Unless somebody malicious can somehow break into this account, they have no way to reset/regenerate our App’s Private Key.

GitHub Permissions

The Renovate App requires the following GitHub Permissions:

  • Write access to code
  • Read access to administration and metadata
  • Read and write access to commit statuses, issues, and pull requests

We will explain the need for each of these here:

Write access to code

Renovate needs write access to code in order to do its job. Although this necessary permission gives us access to all files in a repository, we will only write changes to package.json, package-lock.json and yarn.lock files. These files may be located in any subdirectory too (e.g. for monorepo configurations).

Read access to administration and metadata

This is necessary so that Renovate can learn enough about the repository to detect the right settings without manual configuration. As an example, this permission is used so Renovate can detect:

  • The merge types allowed in the repository (e.g. merge commit, merge squash, rebase)
  • Whether the repository status checks require Pull Requests to be up-to-date with base branch before merging
Read and write access to commit statuses

Currently, Renovate uses only the Read access for commit statuses, in order to know if a Renovate branch has passed or failed tests. Write access is requested in addition to facilitate Renovate adding its own commit statuses in future (such as whether an upgrade is unpublishable, stable, etc)

Read and write access to issues

Currently Renovate does not read or write to issues, but it is planned in future that Renovate will need permissions to create issues in cases such as:

  • Converting a major upgrade from a stale Pull Request to an Issue instead
  • Alerting the user to Renovate configuration problems
Read and write access to Pull Requests

This permission is used heavily today, for instance every time Renovate finds an available update to be tested.

Renovate source code

Although the Renovate App runs as a wrapper around the renovate open source code, the entire logic of the application remains as open source, located at In other words, you can always know what code/logic is running on your repository because we always run the open source code - there is no “fork” of the open source repository in use.

AWS Region

The Renovate App uses Amazon Web Services (AWS) exclusively for running and monitoring the service. Currently all AWS services we use are located in the us-west-2 region (Oregon) in order to be close to GitHub’s API servers and minimise latency. Also, this means that GitHub data is not crossing any virtual country “boundaries” as it remains in the USA.

Debugging and Troubleshooting

We do not “let down our guard” on security when things go wrong or need troubleshooting. For example, we will never extract a copy of the GitHub Private Key so that we can run the app “locally” on any developer laptop.

Renovate will always be run from the “production” server and credentials are never be copied off for debugging purposes. We employ detailed logging by default in order to hopefully have enough of a “black box” to know what happened when something went wrong. Also, we are helped by the fact that problems usually repeat (sometimes every time Renovate runs) so this gives us the ability to expand the debug logging of the renovate app itself if previous runs did not give enough detail.

Log Locations and Retention

All logs are stored in the AWS Oregon region as described above. We currently log to:

  • CloudWatch Logs (30 day retention)
  • Local disk on EC2 (7 day retention)
  • RDS (Postgres) database (long retention but only of high level logs for statistical purposes)
  • S3 (unlimited retention)

As described above, please be aware that no tokens or “secure” data is saved in these logs.

If you leave the service and wish for us to delete your logs, notify us by email and we will ensure they are all removed within a maximum of 30 days.