Provider and renter roles
A provider makes physical or virtualized compute capacity available and keeps it healthy for the active contract. A renter selects capacity and operates workloads inside the granted boundary. One account can use both sides of the marketplace; its Rental Balance and Earnings Balance remain separate.
| Provider is responsible for | Renter is responsible for |
|---|---|
| Stable power, cooling, disks, network, firmware, and compatible GPU drivers | Workload legality, credentials, secrets, data backups, and resource use |
| Accurate listing limits, modes, prices, and availability window | Reviewing the selected hardware, allocation, image, price, and end date |
| Keeping active capacity online and planning maintenance | Stopping workloads and exporting data before ending or expiry |
Platform announcements
The Console can show platform announcements above the current page. Their color communicates informational, successful, warning, or critical context. Some notices can be dismissed; persistent notices remain until ComputeCubed deactivates them. A notice may apply to every account or only selected accounts, and important notices may also be delivered to the email address associated with the account.
Treat the active Console banner as the current notice. Dismissing a dismissible banner hides it for your account across Console sessions, but it does not change the underlying platform state or any active contract.
Listings become contracts
A listing is an offer for future rentals. When a renter launches, ComputeCubed records a contract version with the accepted resource allocation, host earnings price, complete renter price including markup, provider, scope, and contract end date. Later listing edits or delisting affect future renters only; they do not rewrite accepted prices, including recurring periods.
Four allocation modes
| Mode | Scope | What the renter gets | Sharing behavior |
|---|---|---|---|
| Workspace — full node | Node listing | A selected workspace image with the node’s advertised capacity | Exclusive; conflicts with other active allocations on that node |
| Workspace — sliced | Node listing | Chosen CPU, RAM, disk, and optional GPUs | Multiple compatible slices may coexist while capacity remains |
| Kubernetes namespace — unlimited | Cluster listing | A namespace with broad access to the reserved capacity boundary | Exclusive semantics depend on whether a node is reserved |
| Kubernetes namespace — limited | Cluster listing | A quota-bound namespace, service account, optional GPUs, and pinned node | Compatible bounded namespace rentals may coexist |
Private connectivity
Provider nodes initiate outbound WireGuard connectivity; a public IP and inbound port forwarding are not required. Renters generate a rental-specific WireGuard profile after the allocation is ready. Workspace SSH addresses and Kubernetes API access are reachable only through the allowed private routes in that profile.
Never share a join command, WireGuard profile, kubeconfig, private SSH key, or copied token. These are access credentials even when they are short-lived or narrowly scoped.
Important states
| Object | Typical progression | Action if it stalls |
|---|---|---|
| Cluster | creating → ready; may become out of sync or error | Review Activity Monitor, last error, and controller reachability |
| Node | discovered → connected → inventory pending → benchmark pending → ready | Check the join transcript, WireGuard handshake, k3s agent, GPU driver, and cluster GPU family |
| Workspace rental | starting → workspace creating → active/ready → ended | Wait for connection details; use the recorded error if creation fails |
| Namespace rental | starting → active → ended | Download kubeconfig only after active; verify WireGuard before kubectl |