Mirrors

Jenkins packages and plugins are served by the web service get.jenkins.io (or its legacy alias mirrors.jenkins.io).

The web service get.jenkins.io relies on a network of mirror servers provided by generous sponsors of the Jenkins project all over the world. When a user downloads a plugin or a file, the web service get.jenkins.io redirects (transparently) the user to the closest mirror. The web service get.jenkins.io is based on the Open Source mirror redirector mirrorbits.

The list of mirrors (and their locations) is available on the following page: mirror status page.

How to Help the Jenkins Project by Running a Mirror?

Download mirror servers are always welcome to reduce the load on individual servers, to spread the bandwidth costs among multiple servers, and to provide locations close to users.

If you provide (or want to provide) a download mirror server, you’ll have to fulfill the requirements below. We provide the GitHub "jenkins-infra" helpdesk where you can open issues to add/change/delete a mirror or if you have any problem.

Mirror requirements (click for details on each requirement):

An HTTP server to serve files for the end users

  • A public IPv4 and IPv6 (we recommend both). You can have multiple IPs (see below).

  • A valid and resolvable public domain name pointing to your public IPs (we recommend A and AAAA DNS records). Multi-valued DNS records are valid if you have many IPs.

  • Enforced HTTPS with a valid TLS certificate

A storage of at least 300Gb to store ~1 year of files served by the HTTP server

  • As a data point, the "reference" download server, which is archives.jenkins.io, uses around ~600Gb with all of the files.

  • 300Gb of data is enough to provide artifacts published for 1 year (recommended time window). You may clean artifacts older than 1 year (provided by archives.jenkins.io).

A rsync client routine to keep your data up to date from our reference server

  • The data source is rsync://archives.jenkins.io without authentication but we need your outbound IPs to restrict access.

  • We recommend a (differential) data update at least hourly.

  • The file can be deleted if they are more than 1 year old to avoid filling your disks, unless you have at least 600 Gb of data available.

A rsync server to allow regular scans of your mirror

  • Should serve the same data as the HTTP server

  • You can restrict inbound requests using IPs: we provide an API endpoint at reports.jenkins.io/infrastructure/v2/index.json with our rsync/ftp outbound IPs.

    • Check the JSON list at "get.jenkins.io".outbound_ips[]

    • Our scanning IPs do not change often (once a year usually) but we update the JSON daily in case of any change.

A mirror administrator email if we need to contact you

When we need to reach out to the mirror’s administrators (for advertising configuration change or report errors) an email is needed.

If you wish for us to keep this email private, please send it to our jenkins-infra-team@googlegroups.com Mailing List.

The outbound IP(s) used by your rsync client routine

We provide a public rsync without authentication on rsync://archives.jenkins.io for mirrors to update their data but we need to restrict it to only mirrors.

As such, we need your outbound IPs used by your rsync client routine.

We store these IPs in get-jenkins-io-data.json: you can open a pull request on this file to add/change your outbound IPs (even if your mirror is not up to date yet).

Alternatively, you can email them to us at jenkins-infra-team@googlegroups.com or share an API endpoint with us where we can retrieve the IPs regularly.