Bring Your Own Hardware

The Computalot fleet can run on machines that their owners join themselves: a colo box, a workstation, a homelab server. The machine joins with one command. It declares how much of itself it lends. Every task that it runs is walled off from the rest of the machine.

Program status: early access. The Computalot team issues the enrollment codes. The hardware enrolled today is operator-run while we build the host earnings rail. Do you want to lend a machine? Tell us through POST /api/v1/feedback (no auth required, type: "feature_request") or the waitlist on the landing page .

How joining works

The Computalot team enrolls your machine and hands you a one-time enrollment code (cek_…). The code is single-use, and it expires in 24 hours. Everything else happens on the machine itself, as root:


curl -fsSL https://computalot.com/computalot-host -o computalot-host && chmod +x computalot-host
sudo ./computalot-host install --code cek_… --cpus 28 --memory-gb 56

The installer redeems the code over HTTPS and receives the configuration of the machine in exchange. You copy nothing to your machine by hand. Nothing ever connects in: there are no inbound ports, no port forwarding, and no public-IP requirement. After install, the worker only dials out.

The identity of the machine, its recorded hourly rate, and the kinds of work that it can receive are fixed at enrollment, on the Computalot side. A machine cannot rename itself or widen its own permissions. To revoke a lost or leaked code, we issue a new one.

You decide what the machine lends

Computalot never guesses your hardware and never imposes limits on it. The declaration is yours, made in the install command:

Flag	Meaning	Default
`--cpus N`	Lend at most N CPU cores	the whole machine
`--memory-gb N`	Lend at most N GB of memory	all of it
`--gpus all` or `--gpus 0,1`	Which GPUs to lend	none

The lend is enforced outside the worker, as hard systemd or container limits that the workload cannot raise. The lend is exactly what the machine reports upward as its capacity. The fleet therefore schedules only work that fits inside it. On a machine that you still use, leave yourself headroom. A few cores and a few GB keep it responsive, no matter what a task does.

To change the declaration later, run the installer again with new flags. It is idempotent, and it takes a few seconds.

GPUs get an explicit callout. A GPU machine that lends only CPU never exposes its cards, because the default is to lend none. The lend of GPUs is currently limited to the container profile (ask for it at enrollment) while we validate GPU passthrough inside the default sandbox.

What runs on your machine

Four boundaries stand between your machine and the work that it runs. Each boundary is enforced independently:

Every task runs in its own gVisor sandbox. A userspace kernel services the syscalls of the task. Tasks never talk to your kernel directly. The sandbox runs rootless, without any privileged helper.
Every task gets hard resource caps: CPU, memory, and process-count limits carved out of the share that you lent. A runaway task hits its own ceiling, not yours.
Task traffic cannot reach your network. The worker lives in a private network namespace. The egress policy of that namespace rejects the machine’s own addresses, your loopback services, and your local network. Only the internet is reachable.
The worker itself is an unprivileged system user under a hardened systemd unit: no access to /home, a read-only view of the system, and no way to gain privileges. Root is used exactly once, by the installer, in code that you can read. The worker never holds it.

Day to day


`computalot-host status`	worker state, identity, containment status
`computalot-host logs --follow`	tail the worker log
`computalot-host stop`	pause without an uninstall
`computalot-host leave`	remove the worker and everything that install created

leave is always available and always complete. It removes the unit, the sandbox tooling grants, the egress policy, the state of the worker, and its user. Your machine, your call.

Requirements

Ubuntu 24.04 on x86_64 or aarch64
root for the installer (the worker itself runs unprivileged)
cgroup v2 (standard on Ubuntu 24.04) — per-task limits depend on it
docker present at install time only, as a release-extraction tool
curl and outbound internet — nothing inbound

Earnings

The hourly rate of each machine is recorded at enrollment, and customer work is metered on it. The accounting therefore exists from day one. The payout rail is still under construction. This is why the program is early access, and why the hardware enrolled today is operator-run. If you want your machine in the fleet when the program opens, say so through POST /api/v1/feedback.