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 can find instructions for Bitbucket AppPasswords [here](https://confluence.atlassian.com/bitbucket/app-passwords-828781300.html).
Note: you should also configure a GitHub token even if your source host is GitLab or Bitbucket, because Renovate will need to perform many queries to github.com in order to retrieve Release Notes.
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))