Luckily, there is an alternative: we can move all of the configuration of Jenkins into source control. This means that when we deploy Jenkins it is deployed ful

Luckily, there is an alternative: we can move all of the configuration of Jenkins into source control. This means that when we deploy Jenkins it is deployed fully configured, so we can treat the instances as cattle instead of pets. I would take that two steps further: 1. make an OS package of the configuration, and keep the OS package files plus the configuration under revision control (Bitkeeper, git, Mercurial, ...); 2. ditch Docker, because at that point, it's superfluous (the OS' software management subsystem worries about the payload and deployments at that point, for example with Kickstart in RHEL / CentOS, or AutoYAST in SLES, or...) - no code required for installation. We might lose the job build histories when we redeploy (only if we wipe the old Jenkins and redeploy a fresh, but treating Jenkins as cattle implies that this can happen at any time). If keeping the build histories intact is very important to you then you’ll have to solve this yourself or keep treating Jenkins as a pet. That's easy to solve (I already solved it): if Jenkins the application, and Jenkins' configuration is packaged, then the same applies for backup software (Bacula), and backup software's client configuration. Using the AT&T / SVR4 filesystem hierarchy standard specification, Jenkins can be engineered to deliver: - payload in /opt/; - configuration in /etc/opt/; - data in /var/opt/jenkins/. Since the client will be automatically configured via the OS package to backup only /var/opt (no point in backing up packaged application and configuration, since they're under revision control and can be reinstalled at will to replay the machine state), only data can be restored and the instance can continue where it left off, without any loss of state. I already do this at scale. No Docker needed at all, and servers, be they virtual or physical, are completely disposable.