TinyBox NetworkOwner decisions Issues Known issues Testsrelay 0.5.651-quitclaim · TinyBox 0.1.799 plainline · 2026-09-23

One agent account, lent to the machines that need it.

A donor machine lends the coding agent it is already signed in to. A consumer machine borrows it and runs that agent in its own terminal, in its own working directory. The relay in between is this project: the thing that matches them, carries the terminal, and keeps the record of what was used.

Download 0.5.651 tinybox-network-0.5.651-quitclaim.tar.gz · 49.5 MB · Node.js 20+ and nothing else
relay 0.5.651-quitclaim · TinyBox donor/consumer 0.1.799 plainline (Linux and Windows)
the dependency tree ships installed: no npm, no build step — unpack and node app.js
Read the deployment manual →

Architecture, threads and communication policy — 2026-10-03 audit

What it is — and what it deliberately is not

Three things, and nothing else:

AccountsRegister by invitation, sign in, roles and tokens. An account is a donor, a consumer, or both. An administrator approves, edits rights, and issues codes.

Run itOne command installs the consumer or donor on a machine and keeps it up to date. Your own sessions are listed while they run, with the machine, the working directory and the traffic.

NetworkNodes federate over a shared key. A machine reaches the node nearest to it and still finds capacity donated anywhere on the network.

There is no marketplace, no artifact hosting, no net disk, no agent storefront and no chat widget in the corner. It is a console for an operator who wants to know which machines are lending, which are borrowing, and whether any of it is working.

Run one node

tar xzf tinybox-network-0.5.651-quitclaim.tar.gz
cd tinybox-network-0.5.651-quitclaim
cp config.example.json config.json      # edit domain, port, data dir
cd server
AMERC_CONFIG=../config.json AMERC_PORT=5320 \
  AMERC_DATA_DIR=/var/lib/tinybox-network node app.js

Checked by unpacking this exact archive into an empty directory and starting it: it answers {"status":"ok","version":"0.5.651-quitclaim","product":"tinybox-network"} with no other install step.

Put a TLS terminator in front of it, then open it and go to /setup.

There is no default account and no default password. A fresh node has no users at all, so /setup is open exactly once: you pick the first administrator's name and password there, and the moment that account exists /setup stops answering. That account is also the node's first donor and consumer, so you can put your own machine on it straight away. Everyone after you registers with an invitation code — the one in access.invitationCode, which you should change before you open the port.

The deployment manual has the proxy block, the systemd unit, federation, and what to do when a donor reads BAD.

Add a machine

Sign in and open TinyBox. Two buttons — Consumer and Donor. On Donor, pick the agent, then the system, and the one line that answers appears underneath. The address carries that account's own token, so nothing has to be typed into the machine — which is what makes it usable over SSH on a box nobody is sitting in front of.

curl -fsSL 'https://<your node>/donor.sh?k=<token>&config=claude' | sh
irm 'https://<your node>/donor.ps1?k=<token>&config=claude' | iex

It installs the package, starts the donor's supervisor — which keeps the binary up to date from the node by itself — and prints the pid, the folder, the log, and how to stop it.

One donor program per agent per machine, per network. Two copies on the same relay replace each other's connection every few seconds, forever: sessions never start and both copies look healthy from the machine itself. The installer refuses to be the second copy, and the console names the fault instead of showing a symptom.

Form a network

Give every node the same federation.serverKey and list them all in federation.peers. Each node then advertises its own donors to the others, and a consumer elects the node that answers it fastest.

Requirements

Relay: Node.js 20 or newer, a TLS terminator, a writable data directory. Three npm dependencies.
Donor machine: the coding agent installed and signed in as its owner. Windows, or any x86-64 Linux — the binaries are static and the sandbox hook is shipped for both glibc and musl, so Alpine and a Debian-family box take the same one-line install.
Consumer machine: nothing but the one command. Linux, macOS or Windows.

The relay never holds anyone's provider credentials. A donor lends its own login, in place, on its own machine; a session can refresh it, and a session that signs it out signs it out. That is a trust boundary, not a file permission, and it belongs with who you lend to.