Managed Jenkins agents on fresh VMs

A Jenkins agent is the Java process that runs your builds while the controller schedules them. Jenkins charges nothing per agent, so the cost sits in the machines and in the hours your team spends on them. cirunner.dev plans to offer managed Jenkins agents: fresh VMs with more cores and memory, started per build, with no cloud plugin or agent image for you to maintain. Jenkins is on our roadmap and does not work with cirunner.dev today. GitHub Actions and GitLab CI are live in early access. If you want Jenkins next, vote for it on the early-access form.

Where Jenkins build agents get expensive

Jenkins has no hosted agents. You provide every machine. Most teams start with a few static agents, and those agents drift: one has a newer compiler, another holds a workspace that a build depends on by accident, and a third ran out of disk last Tuesday. Builds on the built-in node are worse, since Jenkins' own security docs say they get the same access to the controller's file system as the Jenkins process.

Compile-heavy work makes it sharper. A C++ or game engine build that wants many cores ties up a large machine, so you buy big static agents that sit idle at night. Or you move to on-demand agents and take on the plugin, the images and the boot latency.

What running Jenkins agents yourself involves

• Static agents: create a permanent node, then start agent.jar as an inbound agent over WebSocket, or let the controller connect over SSH. You keep Java and the build tools current on each host.
• Agents on demand: the Kubernetes plugin starts a pod per build from pod templates; the EC2 plugin starts VMs from AMI templates when builds wait for a label. You own the cluster or the AMIs, the IAM permissions and the instance caps.
• One-shot agents: Kubernetes pods by default, or EC2 templates with one executor and Maximum Total Uses set to 1. You pair them with a cache outside the agent, or builds get slower.
• Labels and label expressions route builds, and you set expensive nodes to accept only matching jobs.

Our Jenkins agents on demand guide walks through inbound and SSH agents, pod templates, the EC2 plugin and hardening.

How managed Jenkins agents from cirunner.dev will work

Once we support Jenkins, you will give cirunner.dev your controller URL and an API token for a Jenkins user with the Agent/Create, Agent/Connect and Agent/Delete permissions, and pick a label, for example cirunner, and the machine behind it: more cores and memory, x86 or ARM, a GPU if you need one. Pipelines ask for it with agent { label 'cirunner' }. For each build waiting on that label we create an agent node through the Jenkins API, start a fresh VM and connect it to your controller as an inbound agent over WebSocket with one executor, run the build and remove the VM and the node. A build cache persists between builds. Your controller, jobs and credentials stay where they are. You pay per compute minute.

Static agents vs. cloud plugins vs. cirunner.dev

Who it is for

A good fit if:

• You build C, C++, Rust, Android/Gradle, game engine or CUDA code on Jenkins, and builds get faster with more cores and memory.
• Your static agents drift and your team does not want to own an EC2 or Kubernetes setup for one-shot agents.

Not a fit if:

• Your agents need to sit inside a network that cannot accept an outside machine.
• Your builds are short and a single small agent keeps up.

FAQ

Is there a managed Jenkins agent service?

Not from cirunner.dev yet. Jenkins is on our roadmap. Vote for it on the early-access form and we will tell you when it ships.

Can Jenkins create a new agent per build?

Yes. The Kubernetes plugin creates a pod per build by default, and the EC2 plugin does it with one executor and Maximum Total Uses set to 1. The guide shows both.

Should a Jenkins agent connect over WebSocket or TCP?

WebSocket, in most setups. The agent tunnels through the controller's HTTPS port, so you avoid opening the TCP agent port (50000 in the official controller image).

Do Jenkins build agents need the same Java as the controller?

Agents need a Java version the controller supports. Current Jenkins releases require Java 21 or 25 on the controller and all agents. Your builds can use any JDK you install for the project.