buildbot-worker(7)

✨ buildbot-worker — the manual page, but make it a group chat ✨

okay bestie, this is buildbot-worker(7) from the Services Administration section, and it is literally your cheat sheet for making, upgrading and babysitting Buildbot worker instances. no cap, let's get into it 💅

---

🌸 NAME 🌸

buildbot-worker — worker instances creation, upgrade and management 🛠️✨

---

💖 DESCRIPTION 💖

so, Buildbot worker instances each live in their own little folder under /var/lib/buildbot/workers. that's the whole vibe — one folder per worker, cozy and organized. this manual is here to teach you how to manage them 🫶

---

🎀 CREATION 🎀

want a brand new Buildbot worker instance named $NAME? bestie, it's two commands, and then you're basically done:

buildbot-worker create-worker \
     /var/lib/buildbot/workers/$NAME <master> <name> <passwd>
chown -R buildbot: /var/lib/buildbot/workers/$NAME

after that you can start the worker instance. how you start it depends on which init system you're running — different roads, same slay 💅

🌈 systemd 🌈

to start the instance:

systemctl start buildbot-worker@$NAME.service

to make it start automatically on boot (set it and forget it, main character energy):

systemctl enable buildbot-worker@$NAME.service

and if you wanna fine-tune how the instance gets started — like changing which user runs the process, for example — you can drop in a systemd drop-in:

mkdir -p /etc/systemd/system/buildbot-worker@$NAME.service.d
editor /etc/systemd/system/buildbot-worker@$NAME.service.d/user.conf

with these contents inside:

[Service]
User=my-user
Group=my-group

🦋 sysvinit 🦋

first things first: you gotta edit /etc/default/buildbot-worker and configure your instance. the syntax is pretty self explanatory ngl, but here's an example anyway:

# 1-enabled, 0-disabled
WORKER_ENABLED[1]=1
# short name printed on start/stop
WORKER_NAME[1]="$NAME"
# user to run worker as
WORKER_USER[1]="buildbot"
# basedir to worker (absolute path)
WORKER_BASEDIR[1]="/var/lib/buildbot/workers/$NAME"
# buildbot-worker options
WORKER_OPTIONS[1]=""
# prefix command, i.e. nice, linux32, dchroot
WORKER_PREFIXCMD[1]=""

after which, you may start the instance:

service buildbot-worker start $NAME

and by default? it will automatically start on boot. iconic, no extra work required 👑

---

🔥 UPGRADE 🔥

when you install new versions, each worker instance gets automatically restarted. literally nothing else for you to do. no additional action is required. periodt 💅

💜 upgrade from 0.8.x 💜

so since version 0.9.0 of Buildbot, the "slave"-based terminology is deprecated in favor of "worker"-based terminology. we don't say that anymore, bestie 🚫

if you're upgrading from a 0.8.x version, all your old buildbot-slave instances sitting in /var/lib/buildbot/slaves must be manually migrated. the simplest way to do that is to create new workers re-using the same <master>, <name> and <passwd> arguments. check out the CREATION section of this manual for more details 👀

once you've migrated, you may safely delete the old "slave" directory:

rm -rf /var/lib/buildbot/slaves/$NAME

⚠️ okay real talk for one sec: that rm -rf is the real deal — it deletes things permanently. only run it after you've migrated, and double-check the path. 🫶

---

🌸 FILES 🌸

• /var/lib/buildbot/workers/$NAME — the working directory for the $NAME Buildbot worker instance 🏠
• /etc/systemd/system/buildbot-worker@$NAME.service.d — directory holding the customization drop-ins for the $NAME Buildbot worker instance service ✨
• /etc/default/buildbot-worker — the worker instances services definition for sysvinit users 🧚

---

👑 SEE ALSO 👑

buildbot-worker(1), systemctl(1), systemd.unit(5), service(8)

go read those too, iykyk 💖

---

💜 AUTHOR 💜

Robin Jarry <robin@jarry.cc> — ty for the page, legend 🫶

---

and that's a wrap bestie!! this page is from the buildbot-worker(7) manual, dated 2026-08-03, section Services Administration 💖 go forth and manage those workers, you're gonna eat 🎀✨