Skip to main content
Let’s review common Jenkins agent types and how to declare them in a Jenkinsfile. Agents extend the Jenkins controller by running executors on remote nodes and provide the execution environment for pipeline steps. An agent defines how a node connects to the controller — including the communication protocol and authentication method (for example, JNLP or SSH) — and the node where build tools and dependencies must be installed.
In addition to long-lived (static) agents, Jenkins supports container- and cloud-based agents that spawn ephemeral environments. Docker-based agents run each job in a fresh container built from a specified image, which is ideal when jobs require precise software versions or complex dependencies. This isolation ensures reproducible builds and prevents dependency conflicts between projects.
Agents are simply worker machines — physical, virtual, or containerized — that connect to the Jenkins controller and execute pipeline steps. Choosing the right agent type helps you balance cost, performance, and reproducibility for your CI/CD workloads.
Common agent types and when to use them: Below are Declarative Pipeline examples showing common agent declarations inside a Jenkinsfile. Example 1 — Run the pipeline on any available agent:
Example 2 — Run the pipeline on an agent with a specific label:
Example 3 — Use a Docker image as the agent:
Example 4 — Default (root-level) agent with a stage-level override:
Best practice: set a root-level agent to provide sensible defaults for most stages, and override at the stage level when a specific environment is required (for example, a nodejs Docker image or a windows agent). When using shell steps, reference the agent name with "$NODE_NAME" (or $NODE_NAME in POSIX shells) so the job output clearly indicates which node executed the step.See also: Jenkins Agents Documentation and Using Docker with Jenkins.

Watch Video