Auto-scaling - San Francisco Compute Docs

Use a spot deployment when you want SF Compute to maintain a target number of instances and buy the compute to run them automatically. To scale, update the deployment’s target instance count. The deployment buys compute to cover new instances and offers unneeded compute for sale when you scale down. This pattern is useful for inference workers, batch workers, CI runners, or any other fleet where the desired instance count changes over time.

Prerequisites

SF Compute CLI installed and authenticated (sf login)
Credits on your account (sf billing balance)
A sense of which hardware you want (sf instance-skus list)

Create a pool

sf pools create --name workers

Create an instance template

Define the image and startup script for the instances in the fleet.

startup.sh

#!/bin/bash

mkdir -p /root/.ssh
cat >>/root/.ssh/authorized_keys <<"EOF"
ssh-ed25519 AAAA... you@example.com
EOF

# Start your worker process here

sf instance-templates create \
  --name worker \
  --image ubuntu-22.04.5-cuda-12.7 \
  --cloud-init ./startup.sh

See Instance templates for details on cloud-init and image configuration.

Create a spot deployment

Pass --instance-sku <id> to pin the fleet to specific hardware; see instance SKUs for the catalog.

sf deployments create \
  --type spot \
  --name workers \
  --pool workers \
  --instance-template worker \
  --instance-sku isku_4UpxzQw7A8N \
  --target-instance-count 4 \
  --max-rate 20.00 \
  --min-runtime 2h

The deployment places buy orders for 4 instances. As orders fill, capacity lands on the pool and instances move to running. --max-rate caps what the deployment pays, in dollars per node-hour. --min-runtime sets the minimum continuous capacity window purchased before launching each instance.

Scale up

sf deployments set workers --target-instance-count 8

4 new instances are queued. The deployment buys compute to cover them. Availability depends on matching sell orders within your maximum rate.

Scale down

sf deployments set workers --target-instance-count 2

Excess instances stop and their remaining secured capacity is offered for sale. When a pool’s allocation drops below the number of running nodes, the newest nodes are terminated first. To protect specific nodes from sale, transfer their allocation to a separate pool; see Protect nodes from termination.

Handling interruptions

Spot compute is not guaranteed. Instances may shut down if the market price exceeds your maximum rate or other buyers place reservations that consume the capacity. Design workloads to handle instances being replaced.

Stateless workers. Download model weights on boot. Local disk does not persist between instances.
Health check your load balancer. Route traffic only to instances that are ready.
Longer --min-runtime. A higher value (e.g., 6h) buys a longer guaranteed window per instance but commits more spend per purchase.

Monitoring

sf deployments get workers   # Deployment status, target, and reconciliation
sf instances list            # Individual instance status

Spot-generated orders also appear in the pool’s order history.

Next steps

Adjust --max-rate to control spend

Buy a reserved block of compute on a separate pool with a standard deployment when part of the fleet must not be interrupted:

sf orders create --pool workers-reserved --side buy --nodes 4 --instance-sku isku_4UpxzQw7A8N --start "in 5h" --duration 24h --max-rate 20.00

​Prerequisites

​Create a pool

​Create an instance template

​Create a spot deployment

​Scale up

​Scale down

​Handling interruptions

​Monitoring

​Next steps

Prerequisites

Create a pool

Create an instance template

Create a spot deployment

Scale up

Scale down

Handling interruptions

Monitoring

Next steps