Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.sfcompute.com/llms.txt

Use this file to discover all available pages before exploring further.

If you’re currently using sf nodes, this guide helps you migrate to sf instances.

​
Install the new CLI

curl -fsSL https://cli.sfcompute.com | bash
This aliases the old CLI (which includes sf nodes) to sf-old. You can manage your legacy nodes by running sf-old nodes.

​
Log in

sf login
This opens your browser to authenticate and stores your credentials locally. If it worked, sf me prints the ID of the account you signed in with.

​
Migrate your nodes

Migrate all running and pending nodes with a single command. Running nodes will not stop during the process. 
sf nodes migrate
Found 2 reserved V1 nodes:
  running-node
  pending-node

> Migrate 2 nodes to v2 instances? Yes
✓ Migrated running-node -> instance inst_5M6L6PJ5zpxEjY32w0sxm (capacity cap_6BfPyNg6z9oQm19yW4qw5)
✓ Migrated pending-node -> instance inst_tBgIK7ok0gA50VwXMbcBS (capacity cap_yNHuqxxnxyRcx5QwpzJNd)
Migrated 2 nodes.
For each node, this creates a capacity and an instance inside it. Both are named after the original node. 
sf capacities ls
NAME                       KIND                 NODES               PERIOD
pending-node               market               0                   May 17 → 5am
running-node               market               1                   NOW -> 1PM

sf instances ls
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
NAME                   STATUS               CAPACITY            INSTANCE SKU     CREATED          EXPECTED SHUTDOWN
running-node           running              running-node        richmond         Today, 11:58am   Today, 1:00pm
pending-node           awaiting_allocation  pending-node        richmond         May 1, 4:28pm    -

​
Use your migrated instances

SSH into an instance. 
sf instances ssh running-node
View instance logs. 
sf instances logs running-node
Terminate a running instance. 
sf instances terminate running-node
Rename an instance. 
sf instances set running-node --name new-name
See the instances documentation for the full list of commands.

​
Extend a reservation

Just like with sf-old nodes, instances shut down when their reservation ends. You can check when an instance will shut down. 
sf instances show running-node
│ ID                 inst_Yd21IGhQeoS4qhDJGL9O3
│ NAME               running-node
│ RESOURCE PATH      sfc:instance:sfcompute-com-seb:default:running-node
│ STATUS             running
│ CAPACITY           running-node (cap_j36NeYnyzIO1evQuijevf)
│ INSTANCE SKU       richmond (isku_4UqQKSv27ei)
│ IMAGE              ubuntu-22.04.5-cuda-12.7 (image_TQiHEBzCA18ToAQqBtOr_)
│ CREATED            Today, 11:58am PDT
└ EXPECTED SHUTDOWN  Today, 1:00pm PDT # <-- reservation ends here
Instances shut down when the capacity’s reserved time runs out. 
sf capacities show running-node
│ CAPACITY ID     cap_j36NeYnyzIO1evQuijevf
│ NAME            running-node
│ RESOURCE PATH   sfc:capacity:sfcompute-com-seb:default:running-node
│ KIND            market
│ CREATED         Today, 11:58am PDT
│
│ TOTAL SCHEDULE  Today, 11:58am PDT: 1 nodes # <-- currently reserved
│                 Today, 1:00pm PDT: 0 nodes
Extend the capacity’s reservation, provided there is availability. 
sf capacities extend running-node
See the capacities documentation for more on extending.

​
Create new instances

To launch a new instance (the equivalent of sf-old nodes create --reserved), create a capacity, buy compute time into it, and then create an instance. 
# 1. Create a capacity to hold your compute reservation
sf capacities create --name my-project

# 2. Buy compute time into the capacity
sf orders create --side buy --capacity my-project --nodes 1 --start now --duration 24h --max-rate 2.50

# 3. Create an instance in the capacity
sf instances create --capacity my-project --image ubuntu-22.04.5-cuda-12.7

​
Why separate capacities?

You can run multiple instances in one capacity, but we recommend separate capacities for the use case sf nodes was built for. Actions in a capacity can affect all instances running in it. Imagine Alice and Bob both have a dev instance in the same capacity. If Alice sells back the remaining time on her instance, it reduces the capacity’s allocation to 1. At that point, one of their instances gets terminated - and without careful coordination, it might be the wrong one. Separate capacities avoid this problem entirely.