Migrating from `sf nodes` - San Francisco Compute Docs

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 (pool pool_6BfPyNg6z9oQm19yW4qw5)
✓ Migrated pending-node -> instance inst_tBgIK7ok0gA50VwXMbcBS (pool pool_yNHuqxxnxyRcx5QwpzJNd)
Migrated 2 nodes.

For each node, this creates a pool and an instance inside it. The instance is named after the original node, and the pool is named <node-name>-pool.

sf pools list
NAME                       KIND                 NODES               PERIOD
pending-node-pool          market               0                   May 17 → 5am
running-node-pool          market               1                   NOW -> 1PM

sf instances list
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
NAME                   STATUS               POOL                         INSTANCE SKU     CREATED          EXPECTED SHUTDOWN
running-node           running              running-node-pool            richmond         Today, 11:58am   Today, 1:00pm
pending-node           awaiting_allocation  pending-node-pool            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
│ POOL               running-node-pool (pool_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 pool’s reserved time runs out.

sf pools show running-node-pool
│ POOL ID         pool_j36NeYnyzIO1evQuijevf
│ NAME            running-node-pool
│ RESOURCE PATH   sfc:pool:sfcompute-com-seb:default:running-node-pool
│ 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 pool’s reservation, provided there is availability.

sf pools extend running-node-pool

See the pools documentation for more on extending.

Create new instances

To launch a new instance (the equivalent of sf-old nodes create --reserved), create a pool, buy compute time into it, and then create an instance.

# 1. Create a pool to hold your compute reservation
sf pools create --name my-project

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

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

Why separate pools?

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

​Install the new CLI

​Log in

​Migrate your nodes

​Use your migrated instances

​Extend a reservation

​Create new instances

​Why separate pools?