BOINC or HTCondor for your own computers: what it takes

What “BOINC for my own computers” usually means

The question shows up on BOINC’s own message boards under titles such as “setting up Boinc Server for my personal use”, and on Hacker News as people asking how to borrow compute from another machine while it sits idle. The wish behind it is the same: the BOINC client is pleasant on a desktop (it runs work in the background, backs off when you use the computer and survives restarts), so why not point it at your own jobs?

Two things are different from volunteering for a public project:

• The client is the easy half. The work comes from a project server that someone has to run.
• A BOINC project is designed for computers it does not trust, owned by people it has never met. Much of the server’s machinery exists for that, and you have to set it up even when every computer is yours.

Running a private BOINC project

What it takes, following the BOINC project’s own server documentation:

1. A server. A Linux machine with Apache, MySQL or MariaDB and PHP, and the BOINC server software built from source (the official cookbook uses Ubuntu, ideally in a virtual machine), or the community Docker setup. For a public project the documentation asks for a static IP address, a 64-bit processor, at least 8 GB of RAM and 40 GB of disk; a private one can be smaller, but it is still a web service to keep running and patched.
2. A project. make_project creates its folders, database and web pages.
3. Your application, per platform. Each program is registered as app versions, one per platform: a build for x86_64-pc-linux-gnu, one for windows_x86_64, one for arm64-apple-darwin, and so on. An existing program that knows nothing about BOINC runs inside BOINC’s wrapper, which needs a job description file.
4. Work units. A work generator, or create_work from a script, turns each parameter set into a work unit with its input files.
5. Validation and results. A validator decides whether a result is acceptable (comparing replicas, for untrusted hosts), and an assimilator moves accepted results to where you want them.
6. Attach the clients. On each of your computers, install the BOINC client and attach it to your project’s URL with an account key, from BOINC Manager or boinccmd --project_attach.

Once it runs, BOINC does several things well: clients download work ahead, keep going offline, honour each computer’s preferences for idle time, CPU and memory use and battery, and resume after a restart. The cost is everything above, before the first job, and again for every new program or platform. BOINC applications are also designed to run on one computer each, mostly on one CPU core, which is fine for independent jobs.

HTCondor: built for computers you own

HTCondor came from the same idea, scavenging idle desktops on a campus, but for one organisation’s own machines. Its quick start installs a pool with three commands, one per role, on Linux or macOS:

# the central manager
curl -fsSL https://get.htcondor.org | sudo GET_HTCONDOR_PASSWORD="$htcondor_password" /bin/bash -s -- \
  --no-dry-run --central-manager build-box

# each computer that runs jobs (an execute point)
curl -fsSL https://get.htcondor.org | sudo GET_HTCONDOR_PASSWORD="$htcondor_password" /bin/bash -s -- \
  --no-dry-run --execute build-box

# the computer you submit from (an access point)
curl -fsSL https://get.htcondor.org | sudo GET_HTCONDOR_PASSWORD="$htcondor_password" /bin/bash -s -- \
  --no-dry-run --submit build-box

Windows machines use the MSI installer and the “Setting Up a Whole Pool” instructions instead. A batch is a submit description:

# sweep.sub
executable            = sim.py
arguments             = --alpha $(alpha) --seed $(seed)
output                = out/$(alpha)-$(seed).out
error                 = out/$(alpha)-$(seed).err
log                   = sweep.log
request_cpus          = 1
request_memory        = 1GB
should_transfer_files = YES
queue alpha, seed from params.txt

condor_submit sweep.sub queues one job per line of params.txt, condor_q shows them, and condor_status shows the machines. For computers people use, HTCondor’s configuration templates include a desktop policy (use POLICY : Desktop) that starts jobs only when the keyboard has been idle and the CPU is quiet, and suspends or evicts them when the owner returns.

It is proven at very large scale, and it is a system with its own vocabulary, configuration language and daemons on every machine, designed with an administrator in mind. Jobs run as ordinary processes on each machine, so for code you did not write you add the isolation yourself (a dedicated account, containers on Linux).

Which to use

	BOINC (private project)	HTCondor	Oarbank
Built for	Volunteers’ computers over the internet	An organisation’s own computers	2 to about 20 computers you own and use
Central piece	Web server, database, PHP	Central manager	Coordinator, with a browser console
Your program	App versions per platform, wrapper	Any executable, a submit file	A module, built with the SDK
Windows	Client yes	Yes, with its own installer and setup	Coordinator and nodes
Owner’s own work	Idle, CPU, memory and battery preferences	Desktop policy on keyboard idle and load	Memory guard, caps, fewer jobs while someone uses it, rules for named apps
Isolation	Wrapper; virtual machines optional	Your choice	The OS’s sandbox for every job
Trust in results	Validators, replicas	Up to you	Golden jobs before a node counts, replicas

Where Oarbank fits

Oarbank is a self-hosted job queue for the computers you own: Macs, Linux machines and Windows PCs. One computer runs the coordinator, set up from a browser wizard; every computer that computes runs a node, joined with a one-time code from the console. It covers the BOINC-like part (work runs in the background, the person at the computer comes first) without a public web service:

• Your program, once: a module, built with the open-source SDK (Apache-2.0), declares the platforms it runs on, the CPU, memory and tools each job needs, and its golden jobs, which have known answers. A node runs them before its results count, and replicas on other nodes catch one that drifts.
• The owner first, on every operating system: a memory guard that stops taking jobs and then evicts the fleet’s own when free memory runs low, caps on cores, memory, jobs and hours, fewer jobs while someone uses the computer, rules for apps you name, and backing off on battery (and on macOS and Linux when hot).
• A sandbox for every job: Seatbelt on macOS, Landlock and seccomp on Linux, AppContainers on Windows, with network hosts approved per module.
• Your network only: mutual TLS between nodes and coordinator, no Codonic service in the path and no telemetry.

It is not a volunteer-computing platform: it does not take work from strangers’ computers over the internet. It is not meant for hundreds of machines, where HTCondor and Slurm are proven. And for one sweep across two Linux boxes this afternoon, GNU parallel over SSH is one install away. Oarbank is source-available: free for personal and noncommercial use, with a commercial licence from Codonic for commercial use. Get started walks through a first fleet.

BOINC and HTCondor at home

Can I use BOINC to run my own jobs on my own computers?

Yes, by running your own BOINC project: a Linux server with a web server, database and the BOINC server software, your program registered per platform, a work generator, a validator and an assimilator. Then you attach your computers’ BOINC clients to it.

Is HTCondor a better fit than BOINC for a home cluster?

For computers you own, usually. HTCondor was designed for one organisation’s machines: a central manager, an execute service on each computer and a submit file per batch, with a desktop policy that runs jobs only while the keyboard is idle. It is still a substantial system to configure.

Does HTCondor run on Windows and macOS?

Yes. Its quick-start installer sets up Linux and Mac machines with one command per role; Windows machines use the MSI installer and the whole-pool setup instructions.

What is a lighter alternative for a few computers?

For a one-off sweep on Macs and Linux machines, GNU parallel over SSH. For batch work you run again and again across Macs, Linux machines and Windows PCs that people also use, a self-hosted job queue such as Oarbank.