As an independent open source project, the Jenkins project maintains most of its own infrastructure including services which help to keep the project running. The kind of things that fall into "infrastructure" can span from operating virtual machines, containers, configuring network or developing and maintaining project-specific applications to make the development of Jenkins core and plugins more efficient.

Because we strongly believe in Open Source principles, we also apply them to our infrastructure. As such we consider ourself as an open infrastructure project where everybody is invited to learn, share, contribute.



Jenkins infrastructure is maintained by the Jenkins Infrastructure team. This team consists of Jenkins contributors and volunteers who provide a best-effort support depending on their availability and other commitments. We are always looking for contributors who are interested to improve Jenkins services and to help with maintaining them.

Team structure

This section is under development


Jenkins Infra team has a weekly meeting on Tuesdays, 16:30 UTC. This event is a regularly scheduled meeting to sync on the various ongoing infrastructure initiatives within the Jenkins project. This meeting is open to everyone who is interested. See the Event Calendar for meeting links.

You can find Infra team meeting agenda and meeting notes in this Google Doc.



The Jenkins project runs the most of its infrastructure on Azure, sponsored by Continuous Delivery Foundation. This infrastructure is provisioned from the repository jenkins-infra/azure using Terraform and using AKS charts.

While we try to stick to Azure, we still have machines sponsored by different organizations such as OSUOSL, AWS, Rackspace or CloudBees.

Configuration Management


The Jenkins project’s infrastructure is managed and orchestrated via a git repository named jenkins-infra/jenkins-infra using Puppet. We are also using a Kubernetes cluster orchestrated with jenkins-infra/charts using Helm & Helmfiles.


Infrastructure is monitored via Datadog. Datadog configuration is automated with Terraform on jenkins-infra/datadog

We also provide different dashboard to share the health of our systems.

Status Page



Pagerduty is used to report issues detected by Datadog, we have a follow the sun policy where we try to only be on call during our "available" hours.


Another major aspect of the Jenkins Infrastructure project, is the maintenance of all services either provided by us or third parties. Here is a non-exhaustive list of services that we provide and maintain.

Self-hosted services in Kubernetes

Service JIRA component(s) Repository and links


account, accountapp

Code, helm chart



Code, helm chart

Infra CI -


Release CI -, ci

Code, helm chart

Private artifacts -

helm chart



Code, helm chart

Keycloak identity management

helm chart



Docker, helm chart

SSL certificate renewal

helm chart

Main Website

Code, helm chart

Plugin Site

Code, helm chart

Plugin Site API Backend

Code, helm chart

Polls Site

helm chart

Reports Site

helm chart



Code, helm chart

Wiki Exporter

GitHub Issues

Code, helm chart

Self-hosted services

Service JIRA component(s) Repository and links


Puppet Code

Core and Plugin CI, ci

User Docs, Deployment scripts




Mirrors Puppet scripts (search for mirrorbrain), Mirror scripts, Status page, Running a mirror


Code published with GitHub pages

Update Center






Wiki (deprecated)




Service Provider JIRA component(s) Repository
















Gitter chat system



Content Delivery Network



DNS Registrar



Sub-project/SIG services

Jenkins infrastructure also hosts some services for sub-projects and special interest groups:

Service Owner Sub-project/SIG JIRA component(s) Repository

Website in Chinese

Chinese Localization


Code and Repository Signing

Release Team




Our infrastructure is an open infrastructure project made by and for the Jenkins community. In other words, it’s a contributors driven project. While we can’t share publicly everything like secrets, certificates,…​ we still try to be as transparent as possible so that everybody can understand and improve our infrastructure without having privileged accesses. If you have any idea that could help the infra or interest the community, feel free to make suggestions.

Before going further, we assume that:

Contribution Workflow

In order to contribute to infrastructure project, we ask people to follow the next steps

Pick up a task => Communicate => Implement => Deploy => Review

Pick Up A Task

In order to keep track of the work that needs to be done on the Jenkins infrastructure project, we use the project "INFRA" on Jira. Therefor the first thing to do before any contribution is to find the right ticket, assign it to you, then communicate about it.

If you can’t find an appropriate ticket, please create a new ticket with a clear description of what needs to be done and why. Some jenkins-infra git repository references can help to understand the context. You may also specify components and finally you can communicate about it, using the suggestions from the next section.


While a ticket can have different components assigned to it, we also use the label newbie-friendly to identify task which can be done by a new contributor.


Before any implementation, it’s important to verify that first, there is (still) a need for some implementation and then that no work has been done in the past. The best way for that is to either look after similar Jira tickets, ask on IRC or on the mailing list. You can also join our weekly meetings to discuss and coordinate the changes.

When the subject is too broad or hard to explain in few lines, we write an IEP document which stand for "Infrastructure Enhancement Proposal", the purpose of this document is to explain why we need something, how we want to solve it, and why we took a final decision. Finally, once you have your ticket id, you can start looking for knowledgeable people.

Anyway keep in mind that it’s always better to have too much information than too little and in the end you’ll probably be the best person who can work on your case.

In short
|                                  |
|  Pick up or Create INFRA Ticket  |
|                                  |
     |    |   If no responses after few days
     |    |   promote it on
     |    |                    +------------------------------------------+
     |    |                    |                                          |
     |    +--------------------> IRC: Freenode #jenkins-infra             <----+
     |    |                    |                                          |    |
     |    |                    +------------------------------------------+    |
     |    |                    +------------------------------------------+    |
     |    |                    |                                          |    |
     |    +--------------------> Mail:     <----+
     |                         |                                          |    |
     |                         +------------------------------------------+    |
     | If the topic is too big                                                 |
     |                                                                         |
     |                    +-------------------------------------------+        |
     |                    |                                           |        |
     +--------------------> IEP: |--------+
                          |                                           |


Once there is an agreement about the approach and before any changes, we ask contributors to respect the following rules.

Those rules are just what we consider "best practices" for a contributors driven project and can be adapted depending on specific git repositories.

Rule #1: Everything is in a git repository under the jenkins-infra organization.

So it’s easier for everybody to find/review/audit changes and suggest improvements.

Rule #2: All changes are validated by at least one regular infra contributor via Pull Request.

So we always have different people who understand infrastructure changes.

Rem: Non regular contributors are more than welcome to share their expertise or just ask question which also help to spot incoherences.

Code Reviews Purpose:

  • Educate author and the team about the changes in code being made

  • Discover logic or security issues not covered by tests

  • Gather improvement suggestion for code readability or efficiency

    Rule #3: All Changes are tested on

    So we feel more comfortable when merging PRs and we avoid regression issues.

    Rule #4: Everything is automated.

    So we only have one source of truth and we don’t break others people works. And if it’s not possible, then it needs to be well communicated and documented cf. rule #1.

    Rule #5: All changes follow the Github workflow.
Fork project -> Create Feature Branch -> Open Pull Request -> Ask Review -> Merge


The deployment step is the only moment where we need approval from someone with elevated permission. As already mentioned, even if we try to be as open as possible, we don’t want to share privileged accesses with every contributors even if we trust them and that mainly for security reasons.

Various link which can helpful when looking at the Jenkins infra project