Virtual machines

Virtual machines are currently in beta.

Limitations during the betaCopied!

There are no public IPs. To host an inference server, you’ll need to setup a proxy, like nginx on another cloud (such as digital ocean), connect that cloud to your VPN, and then point your proxy at your nodes.
The VMs do not yet support Infiniband.
The VMs do not currently share a VPC or virtual LAN. If you want this to be the case, configure a VPN.
VMs take about 10 minutes to spin up. If you reboot the machines, you will lose access for a while.
There is no persistent storage. If the underlying node dies due to a hardware issue, you’ll be given another one, but that one will not share the same disk as your previous one.
There is no GPU monitoring, such as active or passive checks on VMs. Some GPUs may “fall off the bus” and not appear occasionally, and you can either reboot the node, or tell us.
If all the VM nodes are taken, and yours dies, you may not get another node. We’ll refund you for the time, but it’s not automatic and you’ll need to tell us.
The VMs do not yet support customer provided images/OSs.
When a contract shrinks the VMs which are removed is not yet user configurable. It will remove the VMs the youngest VMs first (younger VMs haver larger VM ids that can be seen in sf vms list).

We’re working on removing these limitations when VMs exit beta.

QuickstartCopied!

Install the CLI.

curl -fsSL https://sfcompute.com/cli/install | bash

sf login

Add a startup script for your VMs. To be able to access the nodes, this script must configure an SSH key. If you’d like, this can also be a cloud-init user-data file. Run the following to generate a startup.sh.

cat >startup.sh <<SCRIPT
#!/bin/bash

mkdir -p /root/.ssh
cat >>/root/.ssh/authorized_keys <<"EOF"
$(cat ~/.ssh/id_rsa.pub 2>/dev/null)
$(cat ~/.ssh/id_ecdsa.pub 2>/dev/null)
$(cat ~/.ssh/id_ecdsa_sk.pub 2>/dev/null)
$(cat ~/.ssh/id_ed25519.pub 2>/dev/null)
$(cat ~/.ssh/id_ed25519_sk.pub 2>/dev/null)
$(cat ~/.ssh/id_xmss.pub 2>/dev/null)
$(cat ~/.ssh/id_dsa.pub 2>/dev/null)
EOF
SCRIPT

Upload the startup script to the VM.

sf vm script -f startup.sh

Buying virtual machine nodesCopied!

To get VM nodes for a fixed period of time, such as an hour, use the buy command.

sf buy -d '1h' -t h100v # The "-t h100v" opts you into the VMs

SF Compute also offers Kubernetes.

Your nodes will then start spinning up. This will likely take about 10 minutes. You can watch the spin up with.

sf vm logs -f

Connecting to the virtual machine nodeCopied!

You can list out VMs, and then use their IDs to connect, with sf vms ssh.

$ sf vm list 
┌─────┬───────────────────┬─────────┬───────────────────────────────┐
│ ID  │ Instance group ID │ Status  │ Last updated at               │
├─────┼───────────────────┼─────────┼───────────────────────────────┤
│ 156 │ 2                 │ running │ 2025-04-11 16:57:44.736126+00 │
└─────┴───────────────────┴─────────┴───────────────────────────────┘
$ sf vm ssh root@156

Updating the startup scriptCopied!

You can update your startup script by overwriting the existing one.

sf vm script -f updated_script.sh

Startup scripts only run on the first boot of a VM. If you want to run the updated startup script for a VM, run the following command. Running this will lose all of data stored in the VM’s disk (the VM gets deleted then recreated with the new startup script).

sf vm replace -i root@<vm-id> # run sf vm list to view all vms and their ids