Skip to main content

Managing Nodes

This guide covers all aspects of node management, from adding new machines to configuring settings and handling customer requests.

Browserless / agent-driven node management

Every action in this page is also available from the lium provider CLI — same surface as the portal frontend, scriptable, with --json envelopes for AI agents and CI. For example: lium provider node add --gpu-type "NVIDIA H200 NVL" --gpu-count 8 --ip <IP> --port 8080 --price 1.85 --yes.

Adding New Nodes​

Prerequisites​

Before adding a node, ensure:

  1. Node Software Running: Your GPU machine has the node program running
  2. Network Access: Machine is accessible from the internet
  3. Provider connected: Your provider (self-hosted, or the Lium.io Central Provider Server) is running and connected to the portal

Registration Process​

  1. Access Add Node Modal:

    • Navigate to the Nodes page
    • Click the "Add Node" button
    • A popup modal will appear

  2. Fill Required Information:

    • GPU Type: Select from available options (RTX 4090, A100, etc.)
    • GPU Count: Enter the number of GPUs in the machine
    • Machine IP Address: Public IP address of your node
    • Port: Port number where the node program is running
    • GPU Price: Hourly price per GPU (in USD)

  3. Submit Registration:

    • Review all information for accuracy
    • Click "Add Node" to register

Synchronization​

The sync controls below apply when you run a self-hosted provider. If you've opted into the Lium.io Central Provider Server, Lium handles sync for you and these buttons are not needed.

Sync From the self-hosted provider​

Sync nodes from your self-hosted provider to the portal:

  • Purpose: Import node configurations from your self-hosted provider
  • When to Use: After setting up nodes directly on your server
  • Process: Click "Sync From Provider Server" button
  • Result: Nodes configured on your server appear in the portal
Note

When you first login on portal, the sync process will be done automatically for you.

Sync Into the self-hosted provider​

Sync node configurations from the portal to your self-hosted provider:

  • Purpose: Export portal configurations to your self-hosted provider
  • When to Use: After making changes in the portal that need to be reflected on your server if your server lost connection at that moment.
  • Process: Click "Sync Into Provider Server" button
  • Result: Portal configurations are applied to your self-hosted provider
Note

The syncing process is done automatically as long as your self-hosted provider is connected to the portal backend and you barely need to do manual sync at all.

Synchronization

Always ensure your self-hosted provider is running and accessible before attempting synchronization.

Post-Registration Steps​

After successful registration:

  1. Monitor Status: Check that the node appears as active
  2. Configure Settings: Set notice periods and other parameters

Price Management​

Updating Prices​

  1. Access Price Settings:

    • Navigate to your node details page
    • Click the "Update Price" button
    • Enter the new hourly rate per GPU (in USD) in the GPU Price field
    • Note: The Machine Price field is deprecated and will be ignored

  2. Price Considerations:

    • Minimum Viable Price: Set prices that cover your operational costs
    • Competitive Pricing: Research market rates to stay competitive
    • GPU Count Impact: Total rental cost = GPU Price × Number of GPUs rented
Price Updates

Price changes take effect immediately and apply to all new rental requests. Existing active rentals continue at their original rate until they end.

Price limits​

There are two hard constraints on the price you can set:

ConstraintEffect
Price < 0.5× the GPU model's reference pricePortal rejects with HTTP 400 — the price is not saved
Price > 4× the GPU model's reference pricePortal rejects with HTTP 400 — the price is not saved

Reference prices change as the platform adds GPU models or rebalances rates. Always fetch the current values from the machines endpoint:

curl https://lium.io/api/machines

The response lists each supported GPU model with its reference price in USD/hr. Multiply your GPU model's reference price by 0.5 (floor) and 4.0 (ceiling) to get the allowed range.

GPU Splitting​

GPU splitting allows you to rent individual GPUs from a single node to multiple customers simultaneously, enabling more efficient resource utilization and flexible pricing.

Prerequisites​

GPU splitting requires Docker to run on overlay2 with an XFS backing filesystem (pquota, ftype=1). Complete the host-side setup from Docker Storage Setup before continuing — the Edit button on the GPU Splitting panel stays disabled until preflight reports the host as ready.

Setting Minimum GPU Count for Rental​

After configuring the prerequisites, you must set a minimum GPU count to enable GPU splitting on your node.

  1. Access GPU Splitting Settings:

    • Navigate to your node details page in the portal
    • Locate the "GPU Splitting" section in the details panel
    • If your node meets all prerequisites, you will see an "Edit" button

  2. Configure Minimum GPU Count:

    • Click the "Edit" button
    • Set the minimum GPU count (must be greater than 1)
    • Save your changes
Minimum GPU Count

GPU splitting requires a minimum GPU count to be configured. If the minimum GPU count is not set, the node will not support GPU splitting, and customers will only be able to rent all GPUs on the node. Once configured, customers can rent any number of GPUs from the minimum up to the total available GPUs on the node.

Disabling GPU Splitting: You can remove the minimum GPU count to disable GPU splitting. However, you can only remove it when there are no pods currently renting a partial number of GPUs.

Notice Period Management​

Understanding Notice Periods​

Notice periods allow you to schedule maintenance for rented machines while keeping customers informed:

  • Requirement
    • Notice period should be scheduled 24 hours ahead.
    • Maximum period is 60 mins
  • Purpose:
    • Give customers advance warning of planned downtime
    • Give providers a safe maintenance window for the machine

Setting Notice Periods​

  • Go to node management page
  • Find the "Notice Period" section
  • Select the start time. (minimum 24 hours later from now)
  • Enter desired notice period (maximum 60 mins)
Note

Once the notice period is scheduled, it will send an email to the customer who rented the machine and let them know.

Notify Machine Request from Customer​

Respond to customer requests efficiently:

  1. Access Notify Feature:

    • Go to your node details page
    • Click the "Notify" button in the top-right corner
    • A modal window displays available machine requests

  2. Select and Notify:

    • Review available machine requests
    • Select appropriate requests based on your node's capabilities
    • Click "Notify" to send notification to the renter

Force-closing a pod (Mark broken)​

Why this exists & when to use it​

Sometimes a pod's container disappears or dies on your host machine, but Lium still shows the pod as rented. When that happens the node gets stuck: the rental isn't actually running, so the node keeps scoring zero incentive, and you have no way to clear the dangling pod on your own — leaving the machine unusable even after a penalty has been applied.

Force-closing is the recovery path for exactly this situation. By marking the dead pod broken you accept the provider penalty and refund the renter what they paid; in return, the pod is cleared and your node returns to the rentable pool so it can be rented and earn its score again.

Use it when:

  • A rented pod's container is gone or dead on the host but still shows as rented/running in Lium, and
  • You have no other way to recover the node.

It's a recovery tool, not a routine action — it costs you a penalty and disrupts the renter, so only reach for it when the node is genuinely stuck.

How to do it​

  1. Open the node's details page in the Provider Portal.
  2. In the pod status table, find the pod and click Force close / Mark broken.
  3. Read the confirmation, then click Mark as broken.

What happens​

  • A provider penalty is applied: the rental earnings for that pod are declined from you and credited back to the renter for the disruption.
  • The pod's GPUs are released back to the rentable pool, so the node can be rented again and recover its score.
  • For the renter, the pod turns to BROKEN — they're notified they were credited and the pod can only be deleted.
The container is NOT torn down for you

Marking a pod broken only updates billing and state. The platform does not stop the container — you must kill it yourself on the host machine. Otherwise it keeps running and consuming resources.

Tier affects the penalty

On Secure nodes a force-close applies the penalty above. On Spot nodes there is no penalty (renters already accept that Spot pods may be interrupted). See Node Tier: Secure vs Spot.

Node Deletion​

When to Delete a Node​

Consider deleting a node when:

  • Hardware Issues: Machine is no longer functional
  • Upgrade Plans: Replacing with better hardware
  • Cost Optimization: Reducing operational costs
  • Relocation: Moving to a different location

Deletion Process​

  1. Delete Node:
    • Delete from the portal

Troubleshooting​

Common Issues​

Node Not Appearing​

  • Check Registration: Verify all required fields were filled correctly
  • Network Connectivity: Ensure machine is accessible from the internet
  • Provider connected: Confirm your provider is running and connected (self-hosted, or Lium.io Central Provider Server toggle on)
  • Validation: Wait for validation process (minimum 15 minutes) to complete