Although Renovate is now best known as a "service" via the GitHub App, that service is actually running this same open source project, so you can get the same functionality if running it yourself. The version you see here in this repository can be cloned or `npm` installed in seconds and give you the same core functionality as in the app.
There is also a commercially-licensed "Professional Edition" of Renovate available for GitHub Enterprise, that includes a stateful priority job queue, background scheduler and webhook listener.
For details and documentation on Renovate Pro, please visit [renovatebot.com/pro](https://renovatebot.com/pro).
Renovate is available for Docker via an automated build [renovate/renovate](https://hub.docker.com/r/renovate/renovate/). It builds `latest` based on the `master` branch and all semver tags are published too. All the following are valid:
Renovate's official Docker image is compatible with Kubernetes. The following is an example manifest of running Renovate against a GitHub Enterprise server. First the Kubernetes manifest:
```yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: renovate
spec:
schedule: '@hourly'
concurrencyPolicy: Forbid
jobTemplate:
spec:
template:
spec:
containers:
- name: renovate
# Update this to the latest available and then enable Renovate on the manifest
You need to select a user account for `renovate` to assume the identity of, and generate a Personal Access Token. It is recommended to be `@renovate-bot` if you are using a self-hosted server and can pick any username you want.
It is also recommended that you configure `config.gitAuthor` with the same identity as your Renovate user, e.g. like `"gitAuthor": "Renovate Bot <bot@renovateapp.com>"`.
First, [create a personal access token](https://help.github.com/articles/creating-an-access-token-for-command-line-use/) for the bot account (select "repo" permissions).
Configure it either as `token` in your `config.js` file, or in environment variable `RENOVATE_TOKEN`, or via CLI `--token=`.
If you are running on any platform except github.com, it's important to also configure `GITHUB_COM_TOKEN` containing a personal access token for github.com. This account can actually be _any_ account on GitHub, and needs only read-only access. It's used when fetching release notes for repositories in order to increase the hourly API limit.
By default, Renovate will store all files within a `renovate/` subdirectory of the operating system's tempororary directory, e.g. `/tmp/renovate/`.
Repository data will be copied or cloned into unique subdirectories under `repos/`, e.g. `/tmp/renovate/repos/github/owner1/repo-a/`.
Cache data - such as Renovate's own cache as well as that for npm, yarn, composer, etc - will be stored in `/tmp/renovate/cache`.
If you wish to override the base directory to be used (e.g. instead of `/tmp/renovate/`) then configure a value for `baseDir` in `config.js`, or via env (`RENOVATE_BASE_DIR`) or via CLI (`--base-dir=`).
If you wish to override the cache location specifically then configure a value for `cacheDir` instead.
`gitFs` is the recommended way to perform file operations using Renovate. Using `gitFs` means Renovate does a shallow clone to read and subsequently write files for each repository, instead of using platform-specific APIs to read/write files. Platform APIs are still used for things like Issues and Pull Requests regardless.
`gitFs` is supported for all platforms, and is the only approach for Bitbucket Cloud, Bitbucket Server, and Azure DevOps. It's optional for GitHub and GitLab. In the case of GitLab, it is necessary to set `gitFs=ssh` because GitLab does not support write options via git/https when using a Personal Access Token. In this case you need to make sure that Renovate has access to the SSH private key which is associated with its account.
If you wish for git data to be preserved between Renovate runs, then configure `preserveRepoData` to `true` in your bot config. Doing so means that Renovate needs to do only a `git fetch` each time rather than `git clone`. You can control where this data is stored using the `baseDir` config option mentioned above.
`gitFs` means Git is used, which means that commits need a username/email combination. If one is not set for the system that Renovate is run on then you should configure one using the `gitAuthor` configuration option.
It's also possible to sign git commits, but for this you need to set up the GPG key and setting out of band. In short:
- Make sure the private key is added via GPG
- Tell git about the private key (e.g. `git config --global user.signingkey AABBCCDDEEFF`)
- Configure git to sign all commits (`git config --global commit.gpgsign true`)
The following example uses the Renovate CLI tool, which can be installed by running `npm i -g renovate`.
If running your own Renovate bot then you will need a user account that Renovate will run as. It's recommended to use a dedicated account for the bot, e.g. name it `renovate-bot` if on your own instance. Create and save a Personal Access Token for this account.
Create a Renovate config file, e.g. here is an example:
```js
module.exports = {
endpoint: 'https://self-hosted.gitlab/api/v4/',
token: '**gitlab_token**',
platform: 'gitlab',
logFileLevel: 'warn',
logLevel: 'info',
logFile: '/home/user/renovate.log',
onboarding: true,
onboardingConfig: {
extends: ['config:base'],
},
repositories: ['username/repo', 'orgname/repo'],
};
```
Here change the `logFile` and `repositories` to something appropriate. Also replace gitlab-token value with the one created during the previous step.
If running against GitHub Enterprise, change the above gitlab values to the equivalent github ones.
You can save this file as anything you want and then use `RENOVATE_CONFIG_FILE` env variable to tell Renovate where to find it.
Most people will run Renovate via cron, e.g. once per hour. Here is an example bash script that you can point `cron` to:
Note: the GitHub.com token in env is necessary in order to retrieve Release Notes that are usually hosted on github.com. You don't need to add it if you are already running the bot against github.com, but you do need to add it if you're using GitHub Enterprise, GitLab, Azure DevOps, or Bitbucket.
This section describes how to use git binary with ssh for Gitlab, to avoid API shortcomings.
You need to first create a ssh key, then add the public part to Gitlab (see this [guide](https://docs.gitlab.com/ee/ssh/))
Then, you need to create the secret to add the ssh key, and the following config to your container
```
host gitlab.com
HostName gitlab.com
StrictHostKeyChecking no
IdentityFile ~/.ssh/id_rsa
User git
```
To easily create the secret, you can do the following (see [docs](https://kubernetes.io/docs/concepts/configuration/secret/#use-case-pod-with-ssh-keys))
