Hudson Master-Slave Setup: Distributed Build Architecture and Agent Launch Methods

This guide explains Hudson’s distributed build model (master-slave), how jobs are scheduled across nodes, and how to launch slave agents reliably. It is most useful for teams maintaining legacy Hudson installations and for engineers translating older Hudson documentation into modern CI node practices.

Originally published on 2010-07-24; fully revised and updated.

How Hudson master-slave scheduling works

In Hudson, the master handles the web interface, accepts user requests, and coordinates build execution. It can run builds locally or delegate them to slave machines where slave agents are running. Jobs can be pinned to specific nodes or allowed to run on any available node.

• The master remains the central control plane.
• Slave nodes execute delegated builds from the master.
• One machine can host multiple slave agents when needed.
• Users view all job results from the master, regardless of where builds ran.

flowchart TD
    A[Build triggered on master] --> B[Master checks job rules]
    B --> C{Execution target}
    C --> D[Run on master node]
    C --> E[Run on labeled slave]
    C --> F[Run on any free slave]
    E --> G[Slave agent executes build]
    F --> G
    D --> H[Build result returned]
    G --> H
    H --> I[Result visible in master UI]

Where this model helps most

The original guide highlights multi-OS build coverage as a primary use case: for example, running jobs across Linux, Solaris, and Windows. This setup is also useful when you want to offload heavy jobs from the master or reuse existing desktops as occasional build nodes.

Slave agent launch methods compared

Hudson supports multiple ways to connect and launch slave agents. The best choice depends on network reachability, operating system, and operational control requirements.

Original screenshots referenced in the source article: slave launch modes and slave configuration parameters.

Practical setup examples

Unix slave via SSH

• In Hudson, go to Manage Hudson and then Manage Nodes.
• Create a new node and select SSH-based launch.
• Provide host, user, and credentials (password or key-based auth).
• If using keys, ensure the public key is present in ~/.ssh/authorized_keys on the slave.

ssh-copy-id hudson@slave-hostCode language: CSS (css)

JNLP / Java Web Start startup

From the slave machine, open the master-provided JAR location and launch the agent through the JNLP flow.

curl -O http://masterserver:port/hudson/jnlpJars/slave.jarCode language: JavaScript (javascript)

Headless JNLP launch

The source article provides this daemon-friendly pattern. Replace slave-name with the node name configured in Hudson.

java -jar slave.jar -jnlpUrl http://yourserver:port/computer/slave-name/slave-agent.jnlpCode language: JavaScript (javascript)

Custom script launch from master

If built-in modes do not fit, Hudson can run a custom command on the master to establish the remote session and start the agent process.

ssh myslave java -jar ~/bin/slave.jarCode language: JavaScript (javascript)

For this mode, standard input and output are expected to remain connected correctly between master and agent startup command.

Common pitfalls in legacy Hudson node setups

• Network direction mismatch: SSH launch needs master-to-slave access; JNLP depends on slave-to-master reachability.
• Node naming errors: Incorrect slave-name in JNLP URLs prevents agent registration.
• Agent resilience gaps: Browser-launched agents may not restart automatically after host reboot.
• Credential drift: Expired keys or changed passwords break SSH-based startup.
• Resource contention: Using a user desktop as a slave can impact interactive workload during heavy builds.

The original article also notes Hudson commonly running on port 8080 by default and being manageable without superuser privileges, but these should be validated against your actual installation and service model.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.