Liquid capacity

Liquid capacity lets you offer idle BYOC hosts to other Nodus customers and earn Nodus credits. Availability requires published sharing terms and a qualified host.

In BYOC → Pools & machines → Liquid capacity, choose your pool and set Liquid capacity to Yes. This accepts the displayed lending agreement for current and future hosts in that pool. Each host must qualify before lending. The published agreement gives you 50% of eligible settled compute charges in Nodus credits. It records a hardware rate card and reclaim notice; each loan freezes its whole-host rate. Prices are a static snapshot of the lowest matching Nodus website prices. GPU pricing follows the model and physical device count. CPU pricing uses the cheapest proportional published configuration for the host’s vCPUs and usable guest memory. Read the lending terms. Earnings appear after the borrower’s compute charge settles and cleanup finishes. The host table shows which machines are available, lending, reclaiming or awaiting cleanup, with net settled earnings for each host. The host table shows your earning rate per occupied host-hour; idle time earns no credits and demand is not guaranteed. Earnings are spendable Nodus credits; outstanding debt is paid first. Purchased credits and earlier liquid earnings fund owner compensation. Promotional credits do not. Refunded compute charges reduce the corresponding earnings, including after settlement.

Set Liquid capacity to No to stop new loans and interrupt existing borrowed jobs. Waiting Jobs or Workspaces that explicitly target your pool also trigger reclaim. Reuse waits for the host to confirm cleanup; an offline or failed host cannot promise an immediate return.

Submit your Job normally. Nodus automatically compares compatible liquid hosts with other matching capacity on expected cost to completion. There is no borrower opt-in or liquid-capacity checkbox. Your interruption, network, storage, region and private-pool requirements still apply. Liquid jobs use purchased credits or previously earned liquid credits. Promotional credits remain usable on other eligible capacity. A liquid job stops gracefully when its eligible funding runs out, even if promotional credit remains.

Compatible interruptible CPU and GPU Jobs can run on another customer’s host. Host owners can inspect Job data; use explicit private-Pool placement for Jobs that must stay on your own infrastructure. Jobs with secrets, private registry credentials, volumes, source uploads or sidecars use other eligible capacity. Job egress must be Deny; scratch disk must fit the memory request. The image root is read-only. Write results and recovery state in their declared Nodus directories.

apiVersion: nodus.dev/v1
kind: Job
metadata:
  name: community-cpu
  namespace: default
spec:
  image: nodus/python:3.12
  command: [python, -c, "print(sum(range(1000000)))"]
  resources:
    cpu: "1"
    memory: 1Gi
    disk: 1Gi
  placement:
    interruptible: Allow
  network:
    egress:
      policy: Deny

Watch the Job and retrieve logs and outputs through the usual Job commands. Automatic matching considers this supply when eligible; it does not guarantee placement or a particular host. Rate ceilings, budgets and location constraints still apply. Enrolled community hosts have no verified region, so a Job requiring a specific region will use other matching capacity.

For GPU work, request a GPU model and count, as in examples/pools/liquid-gpu.yaml. NVIDIA hosts must pass CUDA execution and cleanup checks. A whole host is lent exclusively; only the requested GPUs are visible to the borrower. Hosts with unsupported drivers, MIG partitions or failed device cleanup stay unavailable. CPU jobs do not occupy GPU hosts.

Host readiness checks CPU load and available memory before offering capacity and again before launch. Draining a host triggers reclaim; removing it waits for cleanup. Nodus checks load periodically; owners still control programs they start directly on the host.

Published checkpoints and outputs are immutable revisions. Credentials from an earlier borrower attempt cannot overwrite an accepted revision or the next attempt’s upload area.