Skip to main content
This feature is in public preview.
A spot deployment is a persistent automation that combines buying compute time on the orderbook with instance management. You create it once. It keeps trying to buy compute time for a single SKU at or below a maximum rate. As allocation becomes available, it creates instances from an instance template. Spot is a buying strategy, not a separate inventory class with a fixed discount. Price and availability depend on sell orders on the SF Compute orderbook. A spot deployment maintains as many instances as the orderbook can supply within your maximum rate. It never exceeds your target instance count.
Spot instances are interruptible. If the deployment cannot keep buying compute time within your maximum rate, it may run fewer instances than the target. It may even stop running instances entirely. Use spot deployments for workloads that can tolerate interruption and recover from checkpoints or durable queues.

​
How it works

The deployment runs a continuous loop.
  1. Calculates how many more instances it needs to reach the target.
  2. Places orders.
  3. Adds allocation from filled orders to the selected pool.
  4. Creates instances from the selected template as allocation becomes available.
  5. Extends compute-time purchases while matching sell orders remain available within the maximum rate.
When you lower the target, the deployment stops excess instances and offers their remaining allocation for sale. It marks affected instances as preempting when a notice applies. The platform stops instances when their purchased compute time ends. Each buy order must fill for its entire requested contract period, but the orders fill independently. The deployment does not wait for the complete target to become available as a group. A target of 8 instances may therefore run anywhere from 0 to 8 instances when orderbook liquidity is limited. The target is a ceiling, not an availability guarantee. If no matching sell order is available within your maximum rate, the deployment remains active and tries again. It does not guarantee a start time or a fulfillment deadline.

​
Create a spot deployment

Create a pool and instance template first, then run the create command.
Set --max-rate in dollars per node-hour. --min-runtime sets the minimum continuous window of compute time that the deployment tries to purchase before launching each instance. It accepts values from 1 minute to 24 hours and defaults to 10 minutes. Boot time counts toward the window, so a short window may leave little or no usable time after the instance starts. Minimum runtime is purchase granularity, not a guaranteed lifetime. The deployment secures a full minimum-runtime block before it launches an instance. Because each buy order is all-or-nothing, it never runs an instance on a shorter sliver. It does not stop a running instance from being preempted (see Preemption). Raising the minimum runtime does not change the price you pay per node-minute, but it can lower the chance of filling. Each order must match sell orders spanning the entire, longer window at or below your maximum rate.
Minimum runtimes of 2 minutes or lower do not include a preemption notice. The in-instance metadata endpoint GET /v1/instance/spot returns {"preemption_at": null} unless the platform already issued a notice. Once set, a notice stays in effect. The platform terminates the instance when its purchased compute time ends.Use these windows only for fast-starting workloads that can stop without advance warning.Above a 2-minute minimum runtime, the deployment uses the standard 2-minute preemption notice. The notice fires when the deployment cannot extend an instance’s compute time.
A spot deployment manages both allocation and instances. It cannot share the same pool and SKU with another spot deployment, standard deployment, or procurement.

​
View spot deployments

Spot and standard deployments share the same commands. The TYPE column identifies spot deployments.
The deployment details include the SKU, maximum rate, minimum runtime, and target instance count. They also show the current reconciliation status. That status is the state and message from the deployment’s latest pass at reconciling orders and instances against the target. List the deployment’s orders with the --deployment filter; the default order list omits deployment-managed orders.

​
Update a spot deployment

Spot deployments use the same update command as standard deployments. Change the target instance count, minimum runtime, instance template, name, or instance name template.
Change the minimum runtime for future compute-time purchases.
Increasing the target queues additional instances and makes the deployment buy the compute time needed to run them. Availability still depends on matching sell orders within the maximum rate.
Lowering the target is an immediate scale-down, not an attrition policy. The deployment may stop excess instances immediately and attempt to sell their remaining allocation through market sell orders. It does not wait for those orders to fill before stopping the instances.Market sell orders take the highest available rate and do not use the maximum buy rate as a sell-price floor. A sale depends on buyer demand. Excess allocation that does not sell remains on the pool until its contract period ends and produces no resale proceeds.
Updating the instance template only affects new instances created by the deployment.

​
Preemption

The deployment marks an instance preempting when it can no longer keep that instance’s compute time secured within your maximum rate. A contract lapses when no matching sell order is available to extend it within your maximum rate. This happens when a competing buyer’s higher bids take the sell orders the deployment needs to extend. A node whose host fails is reported as a failed instance, not a preemption. Lowering the target is not preemption. It is an immediate scale-down that stops excess instances without a preemption notice, so preemption_at stays null for those instances (see Update a spot deployment). The deployment does not preempt an instance while it still holds secured compute time, and it secures a full minimum-runtime block before launching one. So an instance runs at least its minimum runtime unless you lower the target or its host fails. When the deployment preempts an instance, it sets a preemption time about 2 minutes ahead and stops the instance at that time. This 2-minute notice is current behavior, not a guarantee. Minimum runtimes of 2 minutes or lower run without a notice (see Create a spot deployment). Detect preemption by polling the in-instance metadata endpoint GET /v1/instance/spot. It returns the preemption time as {"preemption_at": <unix_seconds>} while a notice is in effect, or {"preemption_at": null} otherwise. There is no push notification or Advanced Configuration and Power Interface (ACPI) event, so the instance must poll. At runtime a spot instance is an ordinary instance. The only differences are that it can be preempted and that the metadata endpoint reports its preemption time.

​
Pause a spot deployment

The CLI does not include a pause command yet. Pause through the update endpoint by setting enabled to false. Get the deployment ID from sf deployments get batch-workers.
Set enabled to true to resume. Pause to stop spending without stopping running work. Pausing stops the deployment from placing buy or sell orders and from creating new instances. Running instances are not extended and lapse when their purchased compute time ends. The deployment removes pending instances that are not yet assigned; assigned instances continue running until their allocation ends. Resuming restarts the automation toward its configured target. Pausing and deleting both leave running instances alone. To stop running instances now, set the target to 0 for an immediate scale-down (see Update a spot deployment).

​
Delete a spot deployment

Delete the deployment when you no longer need it to buy compute time.
Deleting a spot deployment permanently stops it from buying more compute time; unlike pausing, you cannot resume it. Existing allocation remains on the pool until it ends, and instances that are already running continue running on that remaining allocation.

​
Pricing

The maximum rate is the most the deployment pays per node-hour. Spot buy orders clear on the same orderbook as every other order for that SKU; there is no separate spot venue. A filled order executes at the matching sell order’s price, at or below your maximum rate. You pay the seller’s price rather than your maximum. Compute time is billed per node-minute. The deployment’s orders are immediate-or-cancel. Each one matches right away or cancels, so it never rests on the orderbook and leaves no standing hold on your balance. Placing an order still requires enough balance to cover its full contract period at your maximum rate. If your balance cannot cover it, the deployment does not place the order and reports insufficient balance. Waiting does not reserve compute time, and an unfilled order does not purchase compute time or incur a charge. When an order fills, you purchase its complete contract period. You pay for that period at the matched price. This charge includes minutes while the instance is booting, idle, or never becomes healthy. Preemption does not add a charge or round up to another minimum-runtime block; you pay only for the compute time secured up to the stop.

​
When a deployment is below target

Check the reconciliation status with sf deployments get batch-workers, then review the deployment’s filled and unfilled orders with sf orders list --deployment batch-workers. These are the most common reasons a deployment runs below its target.
  • No compatible sell orders are available within the maximum rate.
  • Only some of the independently placed buy orders can fill.
  • Your organization has insufficient balance to place more orders.
  • Purchased allocation is available, but instances are still starting.

​
API reference

Spot deployments use the Deployments API.