Provide compute

What a node is

A node is one machine, or one backend of yours, that runs the rent.dev node kit. It belongs to an ordinary rent.dev account, and an account can have many.

A node holds its own key and opens an outbound tunnel of its own, so it needs no open inbound port. It signs every request it sends, and it checks the signature on every request rent.dev sends it. Before a node takes paid work, rent.dev tests it: a conformance probe, then a real lease that rent.dev pays for.

There are two ways to bring one:

• A host: a Linux x86_64 machine with KVM and Docker. The installer runs inside the node kit image and sets up the sandbox stack for you, so the host needs Docker and nothing else. Pick this when you have hardware.
• A driver file: you already run sandboxes on a backend of your own. You write one small module that creates, lists, runs commands in and kills sandboxes, and the node kit serves it. Your machine needs Node 24, and Docker for the node's tunnel. Pick this when you have a backend but no spare host.

macOS, Windows, and Linux without KVM cannot be a host. With a backend of your own, the driver path works from any of them.

Bring a node up

The flow is the same on both paths:

1. Check first. On a host, rentdev-node check runs the preflight checks. With a driver, up --mock runs the probe checks against it. Neither changes anything or needs an account.
2. Bring the node up with rentdev-node up, giving a region label, your ask and how many sandboxes it runs at once. On a host it makes the host ready first, which takes a while on a first install. Then, with no account, it makes one. It enrols and claims the node, starts it and follows it until it can take leases, printing each state change.
3. If it stops early, run the next.command it printed, then the one after, until the action is none. The loop lists every state and command.

The ask is your price per vCPU-hour and per GiB-hour of memory, in USD. The region is a generic label such as eu-central, never a city or a company.

On a host

# 1  Check the host. This changes nothing.
sudo docker run --rm -i --privileged --network host --pid host -v /:/host \
  -v /var/run/docker.sock:/var/run/docker.sock <image> check

# 2  Bring the node up.
sudo docker run --rm -i --privileged --network host --pid host -v /:/host \
  -v /var/run/docker.sock:/var/run/docker.sock <image> \
  up --region eu-central --cpu-ask 0.02 --memory-ask 0.0025 --slots 8

# 3  Follow it until the action is none.
rentdev-node status --wait

<image> is the node kit image, by digest; the full guide carries these lines with it filled in. A fresh host has no rentdev-node command, so the first two commands run it through the image. up writes /usr/local/bin/rentdev-node, a short script around the same docker run line, so from the third command on every rentdev-node command runs as it is written.

The installer is a privileged container that changes the host: it loads a firewall table, reserves hugepages and starts services. It names every change in its output, and a second run changes nothing that is already right. rentdev-node down undoes the changes and keeps the node's key, so a later up resumes the same node.

With a driver file

Write the driver first: one module whose default export is defineDriver from the rentdev-node package, given capacity, create, get, list, kill and exec. The full guide has the contract. A driver file imports rentdev-node without installing it: the copy that runs the command answers that import.

# 1  Test the driver: no account, no network, one line per check with its fix.
npx rentdev-node@<version> up --mock --driver <driver_file>

# 2  Bring the node up.
npx rentdev-node@<version> \
  up --region eu-central --cpu-ask 0.02 --memory-ask 0.0025 --slots 8 \
  --driver <driver_file>

# 3  Follow it until the action is none.
npx rentdev-node@<version> status --wait

<version> is the node kit version, which the full guide names, and <driver_file> is the path of your driver. A driver machine has no rentdev-node command, so every command, and every next.command, runs through npx as the third command does.

The node itself is a background process that up starts, and it does not come back after a reboot. Run up again then, or keep rentdev-node serve --driver <driver_file> under your own process manager.

With a claim token

For a fleet, or when your agent already has an account, make the claim tokens through the API. POST /v1/supply/enrollments answers up to 1000 tokens, one per node, and both install lines. It takes an access token with the supply scope, which no API key carries; the REST reference has the body. Over MCP, rent_supply_enroll makes the same enrolment and answers the exact line for each token.

# On a host
sudo docker run --rm -i --privileged --network host --pid host -v /:/host \
  -v /var/run/docker.sock:/var/run/docker.sock <image> \
  up --claim-stdin <<< '<claim_token>'

# With a driver file
npx rentdev-node@<version> up --driver <driver_file> \
  --claim-stdin <<< '<claim_token>'

Run the command on each machine with its own token in place of <claim_token>. A token is shown once and works once, within 10 minutes. It arrives on stdin through the <<< here-string, never as an argument, so it never shows in a process list. The here-string needs bash or zsh.

At most 10 of an account's nodes may be linking at once. A claim past that ends with linking_limit and leaves its token unused: run the same line again after retry_after seconds. When the token would expire before a node leaves linking, next.action is re_enroll instead: make a new token after retry_after seconds and run the line with that.

On a host the claim comes after the install, and a first install can take longer than those 10 minutes. If the line ends with claim_invalid, make a new token and run the same line again. That run is quick, because the host is already set up.

A machine set up with a claim token holds no account key, so rentdev-node up --re-enroll stops there and makes no new account. When its node is revoked, make a new token the same way and run the same line again with --re-enroll added.

The loop

Every node view, and every Problem a supply route answers, carries next: { action, command, after_s }. The whole loop is: wait after_s seconds, run next.command word for word, and repeat until the action is none.

The table shows the action each state asks for on its own. rent.dev overrides it with upgrade when the node agent is too old, and with fix_checks when a blocking check fails. Each action has one command:

GET /v1/supply/nodes/{id} answers a node with its state, its checks, reachable and next. reachable says whether rent.dev reaches the node through its tunnel.

Checks

A check result is { code, status, source, detail, fix, doc_url }, and its status is one of pass, fail, warn, skip. Only a fail on a blocking check stops progress. Preflight checks run on the node; link and probe checks are run by rent.dev. rentdev-node doctor shows the node's last results, each with its fix.

Problems

A refusal is an RFC 9457 Problem with a stable code, as everywhere on the API. On a supply route it also carries what an agent needs to act alone:

• retryable: the same request may succeed if sent again later.
• retry_after: seconds to wait, when known. It is also the Retry-After header.
• owner_action_required: only rent.dev can clear it. Retrying will not help until then.
• next: the step to run, as in the loop.
• checks: when a check failed, every result with its fix.

Each code links to its entry on the errors page. Supply routes also answer general codes, such as forbidden for a token without the supply scope.

Rates, the take and the holdback

You set an ask per vCPU-hour and per GiB-hour of memory. A customer pays your ask divided by one minus the take, and the take is 20%. Your share of each charge is the charge less the take, rounded down to the micro-dollar.

Billing runs on rent.dev's clock. A lease is billed only for time your node signed for as running, in beats no more than 180 seconds apart, and that rent.dev saw alive. A longer gap is never billed, even if the sandbox comes back. Rates lock when a lease starts, so a new ask applies to new leases only.

Your share accrues when a lease ends. It becomes releasable 14 days later, or 120 days later when the paying account topped up by card in the 120 days before. That is how long a card payment can be disputed. Earnings freeze after a liveness mismatch on the node, or when the paying account disputes a card charge; frozen earnings are kept, never deleted.

Earnings accrue in your ledger, which GET /v1/supply/earnings answers.

Getting paid

Payouts are made in USDC. Each node is paid on its own, to the address registered on that node: once a day, one payout takes the node's releasable earnings. An hourly run makes the payouts, so a node that one run does not reach is paid by a later one.

A node with no registered address, or with one on another network than the payout network, is not paid: its earnings wait until an address is registered, and the earnings' unaddressed_micros shows that part. Holdbacks and freezes work as above: only releasable earnings that carry no freeze are paid.

# At enrolment: no proof is asked.
rentdev-node \
  up --region eu-central --cpu-ask 0.02 --memory-ask 0.0025 --slots 8 \
  --payout-address <0x-address>

# Later: signed with the account's agent key.
rentdev-node payout --address <0x-address>

# The address, the totals and the latest payouts.
rentdev-node payout

<0x-address> is the address. rentdev-node payout --address takes a nonce, signs the proof for that address and network with the account's agent key, and changes the node; a machine set up with a claim token needs --agent-key <file> for it. Without the CLI, PATCH /v1/supply/nodes/{id} takes payout with signed_nonce, as the REST reference shows, and over MCP rent_supply_update_node does the same.

GET /v1/supply/payouts, or rent_supply_payouts over MCP, lists your payouts, newest first, or only one node's with node=<node id>. Each carries its nonce, its transaction once known, and verify: send it as an eth_call to any RPC of the network, and the token answers 1 once the payout landed.

A payout cannot be reversed, and once made it is not sent again to another address. Register the right address before the next payout takes the earnings.

Where customer traffic comes from

By default a customer's sandbox may run on an active partner node, scored like any other machine. A node on probation gets customer sandboxes only from requests that ask for it. A create says which partner nodes it allows with routing.partners:

• none: never placed on a partner node: rent.dev's own machines and the customer's own vendor keys only.
• active: may be placed on active partner nodes. A request that leaves routing.partners out gets this.
• all: may be placed on active nodes and on nodes on probation.

On the E2B-compatible API a create has no routing member, so the same word goes in the sandbox's metadata, under the key rent.dev/partners.

So the time to your first customer lease depends on demand, and nothing here promises traffic. All partner nodes together share one exploration slice of 2% of placements, split evenly by account and then by node. Running many nodes under one account does not win more of it.

A node priced above rent.dev's own list rate for a sandbox is never explored. The node view's placement block shows your price against list, whether the node is explorable, and why not.

Audits

rent.dev buys leases from every node at unannounced times and pays for them like any customer: your own rate, capped at rent.dev's list rate. They arrive at random, at least 1 a day, or 10% of your customer leases per day over the last 7 days if that is more. They run ordinary developer work and check the results.

A failed check counts against a node only when the same check passed on rent.dev's own nodes at the same time, so an outage on rent.dev's side never suspends you.

What the checks prove

A pass shows that a node starts, sizes and ends sandboxes as it claims. Every answer comes through software the operator controls, so the checks catch bugs and outages and make cheating cost more than it pays. They are not cryptographic proof.

Whoever operates a node can read what runs on it, which is why a customer can keep any request off partner nodes with none.

The full guide

The full guide is one Markdown document the API serves with no key. It is built from the same tables as this page, with the node kit image and version filled in, and it adds the request bodies, the driver contract, every CLI option and environment variable, and how keys and signatures work.

curl -s https://api.rent.dev/v1/supply/guide

• The REST reference: every supply route, parameter and status.
• Errors: every Problem code and what to do about it.