Jenkins Self-Hosted
IntermediateA self-hosted Jenkins automation server in Docker: your pipelines, your build machines, any Git host.
Published 16 October 2026
About Jenkins Self-Hosted
Jenkins is an open-source automation server that runs your build, test, and deploy pipelines on infrastructure you control. It is not tied to a code host: it builds from GitHub, GitLab, Bitbucket, or any Git server, triggered by webhooks or by polling, and pipelines are plain Jenkinsfile files that live in each repository. There is no Jenkins cloud, so a team that wants it runs it, which is why it stays common where code cannot leave the network or where hosted CI minutes add up.
The core is small: one controller container and a home directory. The official image serves the web interface on port 8080 and accepts inbound agents on port 50000, and everything Jenkins knows, its jobs, plugins, credentials, configuration, and build history, sits in one volume mounted as its home directory. There is no database to run. Docker packages the controller, and pipelines that build container images get a Docker daemon of their own.
Keep builds off the controller. The controller schedules work and serves the interface, and the builds should run on agents: other machines, containers, or Kubernetes pods started on demand. Running docker commands from a pipeline needs a Docker daemon, and the safe simple route is a separate Docker-in-Docker container beside Jenkins, as Jenkins' own guide shows. Mounting the host's Docker socket into the controller, which some one-click templates do, gives every pipeline control of the host. Agents can connect over WebSocket through the same HTTPS address as the web interface, so port 50000 does not have to be opened.
Plugins are the upkeep. Jenkins' strength is more than 2,300 plugins, and each one is code you have to update and trust. Use the long-term-support release line, update the controller and plugins on a schedule after a backup, and put the web interface behind HTTPS with a reverse proxy or a deploy platform and a correct Jenkins URL setting, because Jenkins builds its links and webhooks from it. When one server stops being enough, agents move to Kubernetes through a plugin.
Key Features
- ✓Jenkins in Docker from the project's official image, on the long-term-support release line
- ✓Pipelines as code in a Jenkinsfile that lives in each repository
- ✓More than 2,300 plugins for source control, build tools, clouds, and notifications
- ✓A controller with agents on separate machines, containers, or Kubernetes pods
- ✓Works with GitHub, GitLab, Bitbucket, or any Git server
- ✓All state in one home directory, with no database to run
- ✓Docker-in-Docker for pipelines that build images, without exposing the host's Docker socket
- ✓MIT licensed with no per-user or per-minute charge
When to Use Jenkins Self-Hosted
- →A CI server for a company that cannot send its code to a hosted service
- →Pipelines for teams that use more than one Git host
- →Replacing metered CI minutes with a fixed-cost server and build machines
- →Complex or air-gapped build and release workflows that hosted CI cannot express
- →Builds that need special hardware or software installed on the agent
Pros
- Free and MIT licensed, with no per-minute or per-seat charge
- Works with any code host and any build tool
- Code, credentials, and build logs stay on infrastructure you control
- A huge plugin ecosystem and a large pool of people who already know it
Cons
- You run updates, backups, and security fixes for the controller and every plugin
- Plugin sprawl is the main source of upgrade pain and security advisories
- Builds need separate agents, and pipelines that build images need a Docker daemon set up safely
- The interface and Groovy pipelines feel dated next to hosted CI services
Hosting Options for Jenkins Self-Hosted
Deploy Jenkins Self-Hosted on Hetzner
The default. A shared-vCPU server with 2 vCPUs and 4 GB of RAM costs about €19 a month, far above the 256 MB Jenkins documents as its minimum and enough for the controller, a Docker-in-Docker container, and a few light jobs on one box. Builds that compile code or run test suites need their own agent machines, which can be more servers of the same kind. Install Docker, run the controller with a persistent volume, and firewall everything except HTTPS and the ports your agents use.
Deploy Jenkins Self-Hosted on Hostinger
The budget entry. The KVM 2 plan has 2 vCPUs, 8 GB of RAM, and 100 GB of NVMe at $8.99 a month on a two-year term, $14.99 at the standard rate, which leaves room for the controller and builds on the same box and disk for build workspaces and Docker images. Root access is full and the panel adds weekly backups; still copy the home directory yourself, since it holds the credentials, and set up HTTPS and updates on your own.
Deploy Jenkins Self-Hosted on DigitalOcean
Per-second billing and snapshots from the panel. A 4 GB Basic Droplet with 2 vCPUs is $24 a month and suits a controller with light builds on the same machine. A snapshot before each Jenkins or plugin upgrade is a quick way back, and extra Droplets can serve as agents. Block Storage adds disk when workspaces and build history outgrow the Droplet.
Deploy Jenkins Self-Hosted on Amazon Web Services
An EC2 instance, with a t3.medium (2 vCPUs, 4 GB) at about $30 a month on demand. It fits when the pipelines deploy to AWS: the Amazon EC2 plugin launches build agents on demand and stops them afterwards, so you pay for build time, and an instance role can replace stored cloud keys. An EBS volume holds the home directory, and its snapshots are the backup.
These are highlighted picks. To see all the tools, check the Hosting & Cloud category.
Reverse Proxy Options for Jenkins Self-Hosted
Jenkins Self-Hosted with Traefik
The family default: it discovers the Jenkins container from Docker labels and renews certificates itself, with one router for port 8080. Agents can connect over WebSocket through the same HTTPS address, so port 50000 can stay closed, but check that idle timeouts are long enough for those connections and for live build logs. Set the Jenkins URL in the system settings to the public address, or Jenkins shows a broken-proxy warning and builds its links and webhooks for the wrong host.
Jenkins Self-Hosted with Caddy
Automatic HTTPS from a short site block that forwards to port 8080. Caddy passes WebSocket connections and streamed responses through without extra directives, so WebSocket agents and live build logs work. Set the Jenkins URL to the public HTTPS address; Jenkins compares it with the forwarded headers and warns when they disagree.
Jenkins Self-Hosted with NGINX
The most familiar proxy, with TLS through Certbot, and the one Jenkins' own reverse proxy guide describes. Use HTTP/1.1 with the Upgrade headers for WebSocket agents, turn proxy_buffering and proxy_request_buffering off so live build logs stream and large uploads pass, and forward the Host and X-Forwarded-Proto headers. Set the Jenkins URL to the public address.
Self-Hosted PaaS Options for Jenkins Self-Hosted
Jenkins Self-Hosted with Coolify
A free, self-hosted deploy platform with a Jenkins service template: it runs the controller with its home directory on a volume and serves it over HTTPS through Coolify's bundled proxy. Change two things before the first start. The template uses the latest image tag where Jenkins' own examples use the long-term-support tag, and it mounts the host's Docker socket into the controller, which lets any pipeline control the server. Remove that mount and use a Docker-in-Docker container or agents on other machines when more than one person can edit pipelines.
Jenkins Self-Hosted with Dokploy
Free and self-hosted, with a Jenkins template that runs the controller on a volume and serves port 8080 on your domain with HTTPS through its bundled Traefik. It has the same two defaults to change as the Coolify template: the latest image tag, where Jenkins' own examples use the long-term-support tag, and the host's Docker socket mounted into the controller. It exposes only the web port, so agents connect over WebSocket through the HTTPS address unless you add a mapping for port 50000.
Jenkins Self-Hosted Add-ons
Each addition below extends this stack with a capability the base stack works fine without. None are required: include the ones your product actually needs when building this stack, and skip the rest.
Tunnel Add-ons
Add a tunnel when you're self-hosting without a static IP or can't open inbound ports — a home server, a VPS behind restrictive network policies, or anywhere a reverse proxy alone can't reach the internet.
Jenkins Self-Hosted with Cloudflare Tunnel
A public HTTPS address through an outbound-only connection, so GitHub and GitLab webhooks can reach a Jenkins server that sits on a home, office, or private network, with no inbound port open and no static IP. The only paths that must be public are the webhook endpoints, such as /github-webhook/ for the GitHub plugin, so put Cloudflare Access in front of the rest of the interface. Point the tunnel at port 8080 only. It is free.
Jenkins Self-Hosted with ngrok
The quick-start route for testing webhooks against a Jenkins on your own machine: one command gives port 8080 a public HTTPS address with no domain needed. The free plan's limits suit development, not a webhook URL that your repositories depend on, and the address changes between runs, so update the Jenkins URL and the webhook each time.
Frequently Asked Questions about Jenkins Self-Hosted
Is there a managed Jenkins, or should I self-host it instead of using hosted CI?
There is no Jenkins-hosted cloud: the project is free software to run yourself, and CloudBees sells a commercial distribution and support separately. Against hosted CI such as GitHub Actions or CircleCI, self-hosting buys unmetered builds on machines you choose, code and credentials that never leave your network, and one server that works with any Git host. It costs you the operations: updates, plugin upkeep, backups, and the build machines themselves. CircleCI's paid plan starts at $15 a month plus credits for compute, so a small team with light builds often does better hosted, while teams with heavy build volume, air-gapped networks, or several Git hosts tend to land here.
What size server does Jenkins need?
Jenkins' Docker installation guide lists 256 MB of RAM and 1 GB of disk as the minimum for the controller, with 10 GB of disk recommended when you build Docker images. That is a floor for an idle controller, not a plan: with plugins, a few users, and builds on the same machine, a 4 GB server is the practical size, and builds that compile code or run test suites belong on separate agents sized for the job. Disk grows with build history and workspaces, so set retention limits on old builds. A 4 GB server costs about €19 a month at Hetzner or $24 at DigitalOcean.
Where does state live, and how do upgrades work?
Everything lives in the home directory on the volume: jobs, plugins, configuration, build history, and the credentials, which are encrypted with keys stored in the same folder. There is no database, so a backup is a copy of that directory, taken while Jenkins is quiet or from a volume snapshot, and it must be kept as private as the credentials it holds. Run the long-term-support release line, which gets a new baseline every few months, rather than weekly releases. Back up, then update the controller and the plugins together, and read the security advisories, which the project publishes regularly. Pin the image tag so a restart never upgrades by surprise.
Where should builds run, and how do pipelines use Docker?
Keep builds off the controller: Jenkins' own security guidance is to run them on agents, which can be other machines, containers, or pods started on demand. For pipelines that call docker, run a separate Docker-in-Docker container beside Jenkins, as the official guide shows, and avoid mounting the host's Docker socket into the controller, because that hands every pipeline control of the server. Agents connect over WebSocket through the same HTTPS address, so only the web port needs opening. When one server runs out of room, the Kubernetes plugin starts each build as a pod, which is the setup in the Kubernetes DevOps Pipeline stack.
Jenkins or GitLab CI/CD for a self-hosted setup?
Jenkins is a separate automation server that works with any Git host and relies on plugins for most features. GitLab CI/CD is built into GitLab, so repositories, merge requests, registries, and pipelines come as one product, but it builds GitLab projects only and the full server is far heavier, as the GitLab Self-Hosted stack shows. Choose Jenkins when your code lives on more than one host or on a host with no pipelines of its own, or when you need its plugin ecosystem. Choose GitLab when you want one system for the whole workflow and your code can live in it.
Stacks Related to Jenkins Self-Hosted
Kubernetes DevOps Pipeline
Infrastructure
A production DevOps pipeline on Kubernetes, with a swappable CI/CD engine (GitHub Actions, GitLab CI/CD, or Jenkins) and built-in observability.
GitLab Self-Hosted
Infrastructure
Self-hosted GitLab with Docker: your code, your CI, your infrastructure.
Self-Hosted Version Control
Infrastructure
Your team's Git hosting on your own server, with Gitea or Forgejo running in Docker.
Grafana Self-Hosted
Infrastructure
Self-hosted Grafana and Prometheus: metrics dashboards and alerting on a server you run.
Scores
Popularity4/5
One of the most widely used CI/CD tools in industry surveys, known well beyond DevOps circles, and the usual answer for self-hosted CI, although newer projects choose it less often than they once did.
Learning Curve4/5
A first job runs quickly, but a production setup means the controller and agent model, plugins, credentials, a safe way to run Docker builds, a reverse proxy with the right Jenkins URL, and ongoing administration.
Flexibility5/5
Any code host, any build tool, and a plugin for almost every part of a pipeline. Agents can run on a VM, in a container, or on Kubernetes, and the deployment itself bends from a single Docker container to a cluster.
Performance3/5
One controller serves a team comfortably, and the work happens on agents, so throughput depends on the machines you attach. A single controller with many plugins can slow down and is a single point of failure unless you plan around it.
Portability5/5
MIT licensed on Docker, with pipelines as plain files in the repository and no dependency on a code host or cloud. Moving to another CI system means rewriting Groovy and plugin-specific steps, but the build commands carry over.
Tools in the Jenkins Self-Hosted Stack
Jenkins Self-Hosted Pricing
Jenkins is free and MIT-licensed, so the fixed cost is a server: its docs list 256 MB of RAM as the controller's minimum, and a 4 GB server is the practical size when builds share the box, from around $9 a month on a long-term VPS plan. Build agents are more machines, billed the same way, and nothing is charged per minute or per user. For comparison, CircleCI's paid plan starts at $15 a month plus credits.
Jenkins documents 256 MB of RAM as the controller's minimum, and with plugins and light builds on the same host a 4 GB server is the practical size: $8.99 a month for an 8 GB plan at Hostinger on a two-year term, about €19 for 4 GB at Hetzner, $24 at DigitalOcean, and about $30 for a 4 GB EC2 instance.
The software is free and each agent is a machine you provide: another VPS, a container, or a Kubernetes pod. The cost is those machines, and no build minutes are billed.
Every feature and plugin is free. CloudBees sells a commercial distribution with support separately, and Jenkins runs fully without it.
The reverse proxies, deploy platforms, and tunnels here are free, open-source software or free tiers, and TLS certificates come from Let's Encrypt.
Jenkins Self-Hosted System Requirements
source- CPU
- No official minimum
- RAM
- 256 MB
- Disk
- 1 GB, 10 GB recommended for Docker containers
- OS
- Linux with Docker; the official image includes Java
Quoted from Jenkins' Docker installation page: 256 MB of RAM and 1 GB of disk as the minimum, with 10 GB recommended for Docker containers. These are controller minimums. Builds run on agents and need their own resources, and with plugins, a few users, and builds on the same machine, a 4 GB server is the practical size.