Jenkins Kubernetes agents vs static agents: when each model fits
Choose pod agents when your team already operates a Kubernetes cluster and wants a clean environment for every build. Choose static agents when your build tooling lives on stable virtual machines and you have no cluster to run. In both models the Jenkins controller should only handle HTTP requests and manage the build environment, with the actual work done on agents. The decision therefore turns on the skills your platform team already has and on how strictly your builds must be isolated from one another, far more than on raw build speed. Neither model is a universal winner.
Under the Kubernetes plugin, the controller asks the cluster to start a pod for each build, and that pod is discarded when the build ends. This suits teams that already manage node pools, RBAC, image registries and resource quotas, because those skills carry over directly. Static agents are long-lived machines that the controller connects to and reuses. They suit teams whose toolchains are installed and patched on VMs and who would otherwise have to build and operate a cluster only for CI. Ask which model your existing operators can maintain at 2 a.m., not which one benchmarks faster in a demo.
Before you pick, confirm three things with your own environment and with the plugin documentation: who will patch and upgrade the Kubernetes layer, how build caches and tool installations will persist between pods, and how much isolation each pipeline needs from the others. Plan for JENKINS_HOME backup in either model, since the scaling guide places all configuration, plugins and secrets on the controller, not the agents. Teams that already run a cluster should review the Jenkins Kubernetes plugin page before committing to a layout.
How the two agent models compare on the factors that matter
This table compares Kubernetes pod agents created per build by the Jenkins Kubernetes plugin with long-lived static agents on VMs across isolation, tooling, capacity, controller load, configuration and backup. Read each row as a condition to check against your own builds, since most differences depend on how the team configures images, cleanup and storage. The main takeaway is that pod agents trade VM-level state for a cluster dependency, while static agents trade isolation for simpler operations.
| Factor | Kubernetes pod agents (per build) | Long-lived static agents on VMs |
|---|---|---|
| Isolation between builds | Each build runs in a fresh pod from its container image, so files and processes from earlier builds are not present unless a volume is shared. Confirm pod security settings with your cluster policy. | Builds share the same VM filesystem, installed packages and running processes unless the team resets them. Leftover state from one build can affect the next. |
| Tool caching and where tools come from | Tools come from the container images or pod templates defined in configuration. Caches must be backed by volumes or external caches, so their persistence depends on your storage setup. | Tools are installed directly on the VM and persist between builds, which makes caching simple. Version drift across agents is common unless configuration is managed centrally. |
| Capacity and how it scales | The Kubernetes plugin requests pods as builds queue, so capacity depends on cluster resources and any quotas you set. Confirm the plugin's agent limits in your environment. | Capacity is fixed by the number of VMs connected to the controller. Adding capacity means provisioning and registering new machines, which the team must plan ahead. |
| Controller load | The controller launches and tracks agent pods through the Kubernetes API, so controller work includes cluster calls for each build. Plan controller sizing with the scaling guidance and test under your build volume. | The controller maintains long-lived connections to each agent and schedules work onto them. The scaling guide recommends dedicated agents so the controller mainly handles HTTP requests and build coordination. |
| Helm and Configuration as Code setup | The Jenkins Helm chart and Configuration as Code plugin can define the controller and pod templates, but the Configuration as Code plugin does not install plugins. Plugin installation must be handled through images or the Helm chart. | Agent definitions are usually made on the controller or through Configuration as Code, with the agent host prepared separately. Automating VM setup typically depends on your provisioning tools. |
| Backup of JENKINS_HOME | Controller configuration, plugins and secrets still live in JENKINS_HOME on the controller and must be backed up. Pod images and build workspaces are generally rebuilt rather than restored, so confirm which volumes you keep. | The controller holds all configuration, plugins and secrets in JENKINS_HOME, which must be backed up. Agent VMs hold tool installs and workspaces that are often recreated from automation, but confirm what each VM contains. |
| Kubernetes skills required | The team needs working knowledge of pods, images, RBAC, namespaces and cluster upgrades, in addition to Jenkins administration. Confirm which cluster support your team already runs. | The team needs VM provisioning, OS patching and tool management skills. Kubernetes knowledge is optional, though the controller itself may still run on a cluster. |
What each model adds to the Jenkins architecture
Both models keep the Jenkins controller at the center, but they move different parts of the build estate into your hands. Each card below names one component, what it is responsible for and who typically maintains it, so you can size the operating work before you choose an agent layout.
Controller and JENKINS_HOME
The controller serves the web UI, schedules builds and holds all configuration, plugins and secrets in JENKINS_HOME on its disk. The scaling guide recommends keeping it free of build work so it handles HTTP requests and manages the build environment. Your team owns backups of JENKINS_HOME, the plugin set and LTS upgrades in both models. Check that restore has been tested, not just that backups run.
Kubernetes plugin and pod templates
The Kubernetes plugin creates an agent pod for each build from pod templates you define, then removes it when the build ends. Pod templates set the images, tools and resource requests a build receives. Your team maintains the templates, the plugin versions and the credentials that let the controller reach the cluster. Confirm how your plugin version handles pod cleanup and image pulls before relying on it at volume.
Kubernetes control plane and etcd
Pod agents depend on a cluster whose control plane is highly available and whose etcd data is backed up. The kubeadm guide describes stacked etcd or an external etcd cluster with at least three control plane nodes, and Kubernetes documentation asks for an odd member count and an etcd backup plan. Your platform or cluster team usually owns this layer, so ask who is on call for it before you move build capacity onto pods.
VM fleet and agent connections
Static agents are long-lived machines, often VMs, that connect to the controller and stay registered between builds. Your team patches their operating systems, installs and updates build tools, rotates agent credentials and removes drift by hand or with configuration management. Tool caches persist on these machines, which speeds builds but makes contamination between jobs a risk you must manage through labels and cleanup routines.
Proxy and backup controller
The scaling guide describes a primary and backup controller behind a proxy such as HAProxy or F5, which routes traffic to the backup if the primary fails. A backup only helps if it holds current JENKINS_HOME data and plugin sets, so define how state is replicated and who switches traffic. Test a failover at least once, because a standby that has never served traffic is an untested assumption.
Scale-out with extra controllers
The scaling guide describes adding controllers for new teams or projects instead of growing one controller indefinitely. Each controller carries its own JENKINS_HOME, plugins, upgrade cycle and backup job, so operating effort grows with the count. Decide early whether teams share agent infrastructure or each controller owns its agents, and ask what that split means for quotas, credentials and upgrade windows.
Why per-build pods change isolation and tool caching
A pod that the Kubernetes plugin creates for each build starts from an image your team defines, so files, environment variables and credentials left by an earlier job are less likely to reach the next one. The pod is deleted when the build ends, which removes its workspace and installed packages. That benefit depends on the pod template. Check whether it mounts a shared volume, a host path or a persistent workspace, because any of those brings state back between builds. Also check how credentials reach the pod. Injected secrets should be scoped to the job that needs them, not made available to every agent pod in the namespace.
The same clean start means tools cannot be assumed to be present. Compilers, SDKs, scanners and language runtimes must be baked into the agent image or pulled during each build. Either way, tool versions become image versions that someone owns, rebuilds and tags. Static VM agents work differently. Package directories, language dependency caches and Docker layers persist between jobs, which can make repeated builds faster but also keeps state from one job that another job can see. Whether that trade-off helps your workloads is something to measure in your own environment, including how your registry or package mirror is reached from the build network.
Pod Security Standards set the baseline for what build pods may do. Kubernetes defines three levels, Privileged, Baseline and Restricted, and applies one to a namespace through labels such as pod-security.kubernetes.io/enforce. Image builds and Docker-in-Docker steps often need elevated permissions, which pushes teams toward the Privileged level for the namespace that runs agents. Confirm which level your cluster enforces for that namespace, and whether it enforces, only warns or only audits. If builds need exceptions, keep them in a separate namespace with its own service accounts and network rules. The Pod Security Standards documentation describes each level.
How to set up Kubernetes agents with Helm and Configuration as Code
This sequence takes a team from a pinned Jenkins LTS install on a cluster through Kubernetes pod templates and YAML-based controller configuration, ending with a controller that can be rebuilt from its inputs.
Pin the Jenkins LTS line and inventory plugins
The platform owner chooses the Jenkins LTS baseline the team will run and records it in the deployment repository before any install begins. Jenkins picks a new LTS baseline every 12 weeks and ships three LTS releases per baseline in four-week cycles, so the team should decide when it will move to a new baseline and who approves it. Before installing, list every plugin the current controller uses, because LTS 2.580.1 stopped bundling several plugins, including the bouncycastle API, SSH server and JUnit plugins. Done means a written version pin and a plugin list that the team can install from the plugin manager or a Docker image. Ask the vendor or your own release process to confirm which LTS line fits your Java version, since the Java support policy lists Java 21 and Java 25 as supported and Java 17 ended with 2.541.3.
Install the controller with the Helm chart
The platform engineer installs Jenkins onto the cluster with the official Helm chart, pointing the values file at the pinned LTS image and at a persistent volume for JENKINS_HOME. The controller should run with no build executors on itself so that builds land on agents, which the scaling guide recommends for keeping the controller focused on HTTP requests and environment management. Set the chart to mount the storage that will hold JENKINS_HOME, because that directory holds all configuration, plugins and secrets on the controller. Done means the controller starts, the login page loads through the intended ingress, and the persistent volume is bound. Confirm with your storage team that the volume class supports the snapshot or backup method you plan to use for JENKINS_HOME.
Add the Kubernetes plugin and define pod templates
The Jenkins administrator installs the Kubernetes plugin, then defines one or more pod templates in the cloud configuration. Each template lists the containers a build needs, such as a build tool image and a Jenkins inbound agent container, along with resource requests and limits. Pods are created per build and removed when the build ends, so the team should set separate templates for each tool set rather than one large image. Done means a test pipeline with an agent label matching a template starts a pod, runs its stages and exits, and the pod is removed afterward. Confirm which registry holds the agent images and whether your cluster admission rules, including the Pod Security Standards level for the build namespace, allow the containers the templates request.
Write controller settings as Configuration as Code YAML
The platform engineer writes the controller settings, such as the security realm, authorization strategy, cloud definitions and system message, into a YAML file. The Configuration as Code plugin reads YAML from the path set by the CASC_JENKINS_CONFIG variable, and when that is not set it looks for $JENKINS_HOME/jenkins.yaml. Keep the file in version control and mount it into the controller from the chart values so changes go through review. Done means a clean controller restart applies the file and the settings appear in the web interface without manual edits. Note that the plugin does not install plugins, so the plugin list must come from the Docker image or the Helm chart values. Confirm with your identity team which realm and authorization settings your environment requires before you commit them.
Declare plugins in the image or chart values
The platform engineer lists every plugin version the controller needs in the Docker image build or in the Helm chart values, including the Configuration as Code and Kubernetes plugins. This makes the plugin set part of the same version-controlled change that sets the LTS pin. Done means a controller rebuilt from the image and chart values starts with the full plugin set and no manual installs. Plugins that were bundled in older releases but are no longer bundled, such as the SSH server or JUnit plugins if your pipelines use them, must appear in this list before the upgrade.
Handle credentials without storing secrets in plain YAML
The security owner decides where Jenkins credentials and cloud tokens will live before any are created. Kubernetes Secrets are stored unencrypted in etcd by default, so the team must confirm that encryption at rest is enabled for the cluster, that RBAC restricts list and watch access to those Secrets, or that an external store is used through the Secrets Store CSI Driver. Keep secret values out of the Configuration as Code file and reference them instead. Done means a review confirms where each credential is stored, who can read it and how it rotates. Ask your cluster team to confirm the etcd encryption configuration and the access policy in writing, since these depend on your environment and not on the Jenkins chart.
Test an upgrade and check the plugin manager
Before the production controller moves to a newer LTS baseline, the platform engineer runs the same chart values and image on a staging cluster with a copy of JENKINS_HOME. After the upgrade, the engineer opens the plugin manager and checks for plugins that are missing, disabled or flagged as incompatible, then runs a pipeline on a Kubernetes agent to confirm the pod template still works. Done means the staging controller passes the plugin check and a sample build completes. Record the result in the change ticket so the production upgrade follows the same steps.
Back up the inputs and JENKINS_HOME together
The platform owner sets a backup schedule that covers JENKINS_HOME, the Configuration as Code file and the chart values, because the scaling guide notes that all configuration, plugins and secrets live in $JENKINS_HOME on the controller. The team restores a copy into a test namespace to prove the backup works. Done means a restore test brings up a controller with its jobs, credentials and plugins intact. Ask your backup vendor or storage team to confirm consistency options for a running controller, and record who owns restore approval and how long restores are allowed to take in your own runbook.
What upgrades, backups and monitoring demand from each team
This table compares the recurring operating work for Jenkins with Kubernetes pod agents against Jenkins with long-lived static VM agents. Read each row as the ongoing duty the team takes on, and note that the controller and its $JENKINS_HOME backup are the same in both models.
| Area | Kubernetes pod agents | Static VM agents |
|---|---|---|
| Jenkins LTS upgrades | The controller follows the LTS line: a new baseline every 12 weeks, with three LTS releases per baseline in four-week cycles. Plan a rolling upgrade window for the controller on every cycle. | Same controller cadence and upgrade window. Each VM agent must also be kept compatible with the agent version the controller expects. |
| Plugin upgrades | Plugins are installed on the controller and tested against pod templates, so changes can affect pod builds without touching the agent image. | Plugins are installed on the controller, and each VM must keep the tools and runtimes that plugins and build steps call. |
| Java version support | Java 21 (planned end of support September 2027) and Java 25 (planned end of support September 2029) are the supported versions per the Jenkins Java support policy. Keep controller and agent images on a supported Java version. | Same controller Java policy. Each VM needs a matching supported Java runtime installed and patched by hand or by configuration management. |
| Backup of JENKINS_HOME | Back up $JENKINS_HOME on the controller, which holds all configuration, plugins and secrets per the Jenkins scaling guide. Pod templates live in configuration, so they are covered by the same backup. | Same $JENKINS_HOME backup on the controller. Agent node definitions and SSH credentials also need to be captured and tested for restore. |
| Backup of the agent layer | Agents are ephemeral, so there is little state to back up. Kubernetes adds etcd backup work: snapshot with etcdctl and test restores with etcdutl. | VMs hold tool caches and workspaces that are not in any backup by default. Decide what to rebuild from scratch and what to snapshot. |
| Operating system and node patching | Kubernetes version upgrades are a recurring duty, with one minor version at a time and kubelets allowed up to three minor versions behind the API server. Worker nodes still need OS patching. | No Kubernetes layer, but every VM needs OS patching, reboots and drift checks, since each agent is a long-lived host. |
| Agent drift | Pod images are rebuilt from a defined image, which limits drift to the image pipeline. Confirm your image rebuild and scan cadence. | Each VM can drift from its peers over time. Expect configuration management or image baking to keep them aligned. |
| Monitoring | Monitor controller health, queue length and pod scheduling failures, plus the Kubernetes control plane and etcd. Confirm which metrics your Jenkins Kubernetes plugin version exposes. | Monitor controller health, queue length and per-VM disk, CPU and agent connection state. Host-level monitoring is the main signal. |
| Skills needed | Jenkins administration plus Kubernetes operations, including RBAC, etcd backup and cluster upgrades. | Jenkins administration plus Linux operations, patching and configuration management. |
Which model fits which team situation
A team that already runs a Kubernetes cluster and has platform staff who manage it usually gets the most from ephemeral agents. The Kubernetes plugin creates a pod for each build, so the build environment is defined in code, discarded after the run, and sized through the same scheduler that runs production workloads. Capacity grows with the cluster rather than with a fixed pool of machines, and the controller stays focused on coordinating work. The team still needs to own the controller, its plugins and the JENKINS_HOME backup, because those do not move into the cluster for free.
- Per-build isolation: each build starts from a clean image, which removes most state carried between jobs.
- Capacity through the scheduler: build pods compete for cluster resources and scale with node pools, not with hand-managed hosts.
- Configuration as code: the Helm chart and Configuration as Code plugin let you rebuild the controller from files, though the plugin does not install plugins, so the image or chart must carry them.
- Controller load: the controller handles requests and orchestration while builds run elsewhere, as the Jenkins scaling guide recommends.
- Platform dependency: a cluster outage stops builds, so the team must be prepared to operate the cluster itself.
The static model is better when cluster capacity is shared with production and builds need large, long-lived caches or hardware access that pods handle awkwardly. Before choosing, ask who on the team will be on call for the cluster that runs the build pods.
A team whose build tooling lives on virtual machines, with no cluster and no plan to add one, usually fits static agents. Each agent is a machine with the compilers, SDKs and certificates the team already maintains, and the controller connects to it as a long-lived node. This keeps the toolchain familiar and avoids asking the team to containerize every build before it can ship. The trade-off is that the team owns patching, image drift and capacity for every agent, and those costs recur for as long as the agents run.
- Familiar toolchain: builds run where the team already installs and patches tools, with no container image work required first.
- Manual capacity planning: adding throughput means adding machines, which is a provisioning decision rather than a scheduling one.
- Tool caching: long-lived agents keep local caches warm, which can shorten builds with large dependency trees.
- Drift risk: agents accumulate state over time, so configuration management and periodic rebuilds become part of the operating routine.
- Backup scope: the controller's
JENKINS_HOMEstill holds the configuration, plugins and secrets, and must be backed up separately from the agents.
The Kubernetes model becomes the better choice if the team plans to adopt a cluster within the same budget cycle, because the agent layout is easier to change early. Before choosing, ask whether the team can name an owner for patching each agent image and how many agents the peak build load needs.
A regulated team that must show documented build isolation usually needs a model where each build's environment is defined, reproducible and recorded. Per-build pods created by the Kubernetes plugin make that definition explicit: the pod template is version-controlled, each run starts from a known image, and the environment disappears afterward. Static agents can also meet isolation expectations, but the evidence then depends on how well the team controls image builds, host hardening and cleanup between jobs. Neither model removes the need for controls on the controller, which holds secrets and plugins in JENKINS_HOME.
- Reproducible environments: pod templates and images are artifacts that can be reviewed and retained as evidence.
- Clean-state builds: ephemeral pods reduce cross-build contamination, although shared volumes or cached credentials can reintroduce it.
- Secrets exposure: pods need careful secret scoping, and the Kubernetes secrets guidance says Secrets are stored unencrypted in etcd by default unless encryption at rest is configured.
- Hardening scope: pod security settings and cluster RBAC become part of the control set, similar to host hardening for static agents.
- Evidence production: DeployOpen prepares systems and evidence for assessments, but auditors and certification bodies issue any findings.
Static agents may be easier to defend when the regulator or auditor expects dedicated hosts for certain workloads. Before choosing, ask which control framework applies and which isolation evidence the assessor will request.
A team migrating from a single long-lived controller that runs builds on its own host is often moving from the static model without realizing how much state it holds. The migration question is usually not which agent layout to pick but how to separate build execution from the controller and document what the controller owns. Jenkins guidance recommends dedicated build agents so the controller only handles HTTP requests and manages the build environment. The Jenkins scaling guide also describes adding controllers for new teams or projects, and a primary and backup controller arrangement behind a proxy such as HAProxy or F5.
- Separate execution first: moving builds off the controller is a smaller step than changing agent type, and can be done before any Kubernetes work.
- Configuration as Code: exporting settings to YAML makes the controller rebuildable, but the plugin does not install plugins, so plugin lists must be managed separately.
- Plugin changes: check plugin behavior against the current LTS line, since the 2.580.1 changelog notes several plugins are no longer bundled.
- Controller sprawl: adding controllers per team adds backups and upgrades to track, so decide the controller count early.
- Backup of `JENKINS_HOME`: take a verified backup before any agent change, and test a restore on a separate host.
A direct move to Kubernetes agents can be the better choice when the team wants to retire static hosts entirely, but only after the controller is stable. Before choosing, ask how many jobs depend on controller-local files or tools, because those break first when builds move.
What running the Kubernetes layer under Jenkins adds to the work
Pod agents move the build fleet onto a Kubernetes cluster, so the Jenkins team inherits a second platform with its own upgrade rhythm. Kubernetes ships approximately three releases a year on a cycle of about 14 weeks, and the project maintains only the three most recent minor releases. As of September 2026 those were 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027), according to kubernetes.io/releases. Kubernetes 1.19 and newer receive about one year of patch support. Plan a standing upgrade window, and check the Kubernetes version skew policy before each one: kube-apiserver goes first, one minor version at a time, and kubelets may run up to three minor versions behind it. Confirm that the Jenkins Kubernetes plugin and your pod templates work on the target version before you move the control plane.
The control plane is the part most teams underestimate. The kubeadm high availability guide describes a stacked topology, with etcd on the control plane nodes, and an external etcd topology, with etcd on its own nodes. Either way you need at least three control plane nodes and a TCP load balancer in front of kube-apiserver on port 6443. Kubernetes documentation says etcd should run with an odd number of members, recommends a five-member cluster in production, and requires a backup plan. Take snapshots with etcdctl snapshot save and plan restores with etcdutl, and rehearse the restore before you need it. Secrets are stored unencrypted in etcd by default, so Jenkins credentials that reach the cluster need encryption at rest and least-privilege RBAC as well.
A team that cannot staff this work has two sensible options. It can buy a managed Kubernetes cluster from its cloud or hosting provider, but it should confirm in writing who patches the control plane, what the etcd backup and restore responsibilities are, and what support covers the cluster. Or it can keep long-lived static agents on virtual machines, where the operating system patching is simpler to hand off. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and it scopes Kubernetes cluster work only in a written, fixed-scope agreement agreed before any work starts. Ask any provider, including us, to name the upgrade cadence, the etcd backup owner and the restore test frequency in that agreement.
How much effort and cost does each agent model take to run?
What does running Kubernetes pod agents cost compared with VM agents?
Neither model has a published price from us, and the difference depends on who pays for which layer. Pod agents add a Kubernetes cluster you must staff, patch and back up, but they can share node capacity across teams and create build environments on demand. Static VM agents cost less to stand up, yet each VM needs its own operating system patching, tool installs and capacity planning. Ask for a quote that separates one-time work (cluster build, pipeline templates, image pipeline) from recurring work (node upgrades, image rebuilds, VM patch windows, backup testing, support hours) so you can compare the two models line by line.
Can our team run Jenkins agents without an outside consultant?
A team that already operates Kubernetes and Jenkins can usually run static agents without outside help, because the moving parts are few. Pod agents depend on cluster skills: RBAC for the Jenkins service account, pod templates, image maintenance and node capacity. Teams without that experience often underestimate the on-call load. Before deciding, confirm whether your staff can own the cluster upgrade cycle, the controller and plugin upgrades, and the restore test for JENKINS_HOME. If any of those are gaps, a fixed-scope engagement with written deliverables can cover the setup and handover, and ongoing support can be a retainer.
How long does a Jenkins agent implementation take?
The duration depends on the number of pipelines, the number of build toolchains, the cluster that already exists, and how much of the setup is Configuration as Code. We do not publish a timeline, and a fixed-scope agreement sets one in writing before work starts. Static agents can often be reproduced on existing VMs quickly, while pod agents need image design, network and storage decisions, and a controller that is configured from YAML. Ask for milestones tied to specific deliverables, such as a working pod template, a tested rebuild of the controller from its configuration, and a documented rollback path.
What do we need to provide before implementation starts?
You provide the access and facts that a plan cannot be built without. This includes the Jenkins version and plugin list, the Kubernetes version and distribution, cluster capacity and network policy, the build tools each pipeline needs, and the secrets store you use. For static agents, list the VMs, their operating systems and patch windows. Also confirm who approves changes and where backups are stored. Gaps in this list usually become change requests later, so request a written scope that names each dependency and the party responsible for it.
How do we back up JENKINS_HOME, and does that cover the agents?
Backing up JENKINS_HOME covers the controller state: configuration, plugins and secrets, as the Jenkins scaling guide notes. It does not cover the build environment itself. For pod agents, the pod templates and images are the authoritative definition, so keep them in version control and rebuild from them rather than restoring old agents. For static agents, the VM images or configuration management code must be recoverable separately. Ask the provider to test a full restore on a clean host, including credentials and the Configuration as Code file, and to document how long that test takes in your environment.
Does running Kubernetes for pod agents add upgrade work we must plan for?
Yes. Kubernetes releases about three times per year on a cycle of about 14 weeks, and the project maintains only the three most recent minor releases. The version skew policy requires the API server to be upgraded one minor version at a time, before the controller manager, scheduler and kubelets, and kubelets may be up to three minor versions older. Plan for each upgrade to touch the cluster, the Jenkins Kubernetes plugin compatibility and pod images. Static VM agents avoid this layer but still need OS and tool updates. Ask for the upgrade calendar and who performs each step.
Which agent model is easier to leave later?
Static agents are usually easier to leave because they are plain VMs that run the Jenkins agent process, so you can move them to another controller or stop using them without rebuilding a platform. Pod agents tie your build definitions to a specific cluster, namespace layout, image registry and pod template conventions, which are useful but harder to move. Pipelines in a Jenkinsfile stay portable in both cases, but the infrastructure around them is not. Ask any provider to document the exit path, including where images, templates and Configuration as Code files live.
How DeployOpen scopes and delivers Jenkins agent deployments
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including Jenkins agent layouts. We start from a written scope that sets out how build pods or static agents will run in your environment before any work begins.
How we scope
- Map which build workloads need container isolation and which need specific VM or hardware agents.
- Record the Kubernetes cluster, namespaces, node pools and capacity limits the agent design will depend on.
- Agree in writing how the controller, agent images and plugin set will be deployed and who owns each part.
How we build
- Configure the Kubernetes plugin pod templates, or static agent connections, to match your toolchain and tests.
- Set up JENKINS_HOME backup, Configuration as Code files and Helm values as version-controlled deliverables.
- Test agent provisioning, controller load and failure recovery in a staging environment before cutover.
How we hand over
- Document the agent architecture, pod templates, image build steps and runbooks for your platform team.
- Walk your engineers through restoring JENKINS_HOME and rebuilding agents from the documented configuration.
- Deliver the scope's written test results and open items so your team knows what is still pending.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Retainers can cover Jenkins LTS upgrades, plugin updates and Kubernetes version changes affecting agents.
- Ask any provider to confirm in writing who patches agent images, who owns cluster upgrades and who responds to incidents.
