What are Agents in jenkins?

Agents can connect to the controller using several methods depending on network topology and security requirements. The most common is launching agents via SSH, where the controller initiates the connection. For environments where agents are behind firewalls, the JNLP (Java Web Start) or WebSocket methods allow agents to initiate outbound connections to the controller. In containerized environments, agents can run as Docker containers or Kubernetes pods that spin up only when needed and terminate after job completion.

Agents can be tagged with labels that describe their capabilities, such as 'linux', 'docker', 'high-memory', or 'arm64'. When defining a job, you specify label requirements, and Jenkins automatically assigns the job to an agent that matches all required labels. This abstraction decouples build logic from specific machine names, making pipelines more portable and infrastructure more flexible.

Jenkins includes a built-in node that runs within the controller process itself. While technically capable of running builds, this is strongly discouraged for security, performance, and scalability reasons. Best practice is to configure the built-in node with 0 executors and route all build work to dedicated agents. This separation ensures the controller remains responsive for scheduling and user interface tasks regardless of build load.

Agents operate with the permissions of the user account they run under. For security, production deployments should enable SSL/TLS for controller-agent communication, use SSH keys rather than passwords, and consider using ephemeral agents in containerized environments to ensure clean, isolated builds. The controller also needs to verify that connected agents are authorized to perform the tasks assigned to them.