SkyPilot vs SpotWarp Setup Guide Docs Blog Partners Pricing

100% Local Execution • Zero-Key Storage • Published on PyPI

Stop Losing Training Runs to
Spot GPU Evictions

The real cost of an eviction was never the downtime — it's the hours of progress that vanish with it. SpotWarp is built for SaladCloud. It runs continuous automatic backups of your container workspace to your own machine, and when a node is reclaimed it restores that workspace onto a replacement SaladCloud node and restarts your job, so recovery is hands-off too.

1-Liner Auto Setup

curl -fsSL https://gpu-action.com/install.sh | bash

Non-Root / Zero Sudo Required HTTPS-Encrypted License Check Python 3.8+ Native Package

Get SpotWarp Pass

Built for SaladCloud Container Engine

SaladCloud

PyTorch 2.1 / CUDA 12.1 Recipe

Open Source Client

Architectural Comparison

SpotWarp vs. SkyPilot: Which Tool Fits Your Stack?

SkyPilot (UC Berkeley) is a respected open-source tool for running jobs across many clouds. SpotWarp is a focused failover client built for SaladCloud. Here is how they differ.

Dimension	SkyPilot (Open Source)	SpotWarp Built for SaladCloud
Supported Platforms	Many Clouds Multi-Cloud and Kubernetes AWS, GCP, Azure, Kubernetes, RunPod, Lambda and more. SaladCloud is not in its documented list.	SaladCloud Built for SaladCloud Watches and recovers your container group through the SaladCloud public API.
Setup	Per-Cloud Credentials Connect Each Cloud Install, then connect each cloud with its own CLI or credential file and check it with `sky check`.	Two Commands One Salad API Key `pip install spotwarp`, then `spotwarp init` with your SaladCloud API key, organization and project.
Where Checkpoints Live	Bucket or Volume Storage You Provide A cloud bucket mounted with `file_mounts`, or a Kubernetes volume. The instance's local disk is not kept across a recovery.	No Bucket Your Own Machine `/workspace` is copied to your machine over SSH in the background. No bucket, no storage bill.
Keys	Cloud Credentials Configured per Cloud Uses your cloud provider credentials, set up for each cloud you use.	No Keys in the Container Key Stays on Your Machine Your SaladCloud API key never leaves your machine, and the container holds no credentials at all.
Job Definition	YAML SkyPilot Task File Jobs are described in a SkyPilot YAML file and launched with `sky jobs launch`.	No Job File Your Container, Unchanged Your container runs as usual. `--resume-cmd` restarts your own training command after a restore.
Recovery	New Cluster Relaunch Anywhere Provisions a new cluster, possibly in another region or cloud, and restarts the job.	Warm Standby Same Container Group Uses the replacement node in the same Salad container group (a warm standby by default), restores `/workspace` and runs your resume command. 17.1 s in our test with the standby running.
Price	Free Open Source Free and open source.	Subscription $49 / month or $490 / year Open-source client. Salad users get 50% off the first 3 months with code SALAD.

Which One Fits

SkyPilot is an excellent open-source tool when you run across many clouds and already keep checkpoints in cloud storage.

If you run on SaladCloud and want your checkpoints on your own machine, restored automatically without buckets or job files, SpotWarp is built for exactly that.

Get SpotWarp Pass ($49/mo)

Continuous Automatic Backup

Your workspace is synced to your local machine in the background the whole time your instance runs — not just triggered after an eviction. This is the part that actually prevents loss; everything else just makes recovering from it fast.

Same-Cloud Failover with a Warm Standby

SpotWarp checks your SaladCloud container group every 5 seconds and, by default, keeps a second replica running as a warm standby. When your active node is lost, it restores your workspace onto the standby and restarts your job. The standby is billed by SaladCloud like any other replica.

100% Local Zero-Key Leakage

Your SaladCloud API key NEVER leaves your host machine. The spotwarp daemon executes locally on your server. Only subscription validation is verified centrally.

Open Source

Open-Source, Auditable Client

We believe developers should never trust closed binaries with production access. The client daemon is open source and auditable on GitHub.

Open Core Source

Audit every single line of Python code before running on your infrastructure.

SaladCloud Container Image

The container image used by our SaladCloud recipe (PyTorch 2.1 / CUDA 12.1). The failover daemon itself runs on your own machine.

docker pull ghcr.io/enplabs/spotwarp:pytorch2.1

17.1s

Recovery in Our Live SaladCloud Test (Standby Ready)

SHA-256

Checkpoint Identical After Restore

Salad → Salad

Same-Cloud Recovery

100%

Local Key Isolation

Engineering Test Record

What We've Actually Tested

SpotWarp is new, so instead of quoting customers we don't have yet, here is the real test record from SaladCloud: what we deployed, what we forced to fail, and what recovered. It is one run, so treat it as a measurement, not a guarantee.

2026-10-21 17.1 s

Forced node loss on live SaladCloud

Ran the real daemon (the code released as v3.5.1) against a live SaladCloud container group, then forced the active node to be reallocated through the SaladCloud API. With the warm standby already running, the daemon restored the workspace onto it and restarted the job 17.1 seconds after the node was killed.

2026-10-21 BYTE-FOR-BYTE

Backup and restore integrity

A 5 MB checkpoint written on the first node reached the local machine 16 seconds after the daemon started. After the restore, the file on the replacement node had the same SHA-256 hash as the original, and the resume command ran on the new node.

What the time excludes SALADCLOUD TIMING

Allocation is SaladCloud's time

In the same test, SaladCloud took about 8 minutes to give us the first running node (allocation, image download and container start), and the standby needed about 4 minutes after the daemon started before it was ready. The 17.1 seconds applies once a standby is running. Without one, a replacement has to be allocated first, which takes minutes.

Found by testing FIXED IN v3.5.1

A bug our own testing caught

In v3.5.0 the warm-standby step failed silently because of a missing helper, so the daemon never added the second replica and recovery had to wait for a brand-new node. We found it by running the real daemon end to end and fixed it in v3.5.1. We mention it because this is the kind of thing you only find by actually deploying.

Check it yourself REPRODUCIBLE

You don't have to take our word

The client daemon is open source, the package is public on PyPI, and every release binary ships with a SHA256 checksum. Read the failover code before you run it. That is the point of shipping it open.

And what we haven't done yet

The warm standby is a second running replica, so it roughly doubles the container cost while it runs. That is billed by SaladCloud, not by us. It is on by default and can be turned off with --no-standby; without it, recovery waits for SaladCloud to allocate a new node.
The 17.1 second figure is a single run with a 5 MB checkpoint and a short resume command. Larger workspaces take longer to restore, and we have not yet published results for them.
The node was removed through the SaladCloud reallocate API. We have not yet recorded a recovery from a node that disappears on its own.
On Windows, backups use scp and copy the whole workspace each cycle. Linux and macOS use rsync and copy only what changed.
There is no real-time alerting yet. If a failover fails, it is logged locally and nobody is paged.
The Windows binary is not code-signed, so SmartScreen may warn on first run. Verify the checksum if that concerns you.

We would rather you read this before subscribing than discover it afterwards. The 14-day money-back guarantee covers you either way.

Transparent Software Pricing

One Price, Per Machine

No tiers, no per-GPU counting. One license protects everything running on that machine. You pay SaladCloud directly for your containers. This is just the Guard subscription.

Backed by a 14-day money-back guarantee on both plans. Cancel anytime.

Have a Promo / Creator Code?

SpotWarp Monthly Pass

Flexible monthly billing. Cancel anytime.

$49 / month

Continuous Automatic Workspace Backup
Warm-Standby Failover (optional, 17.1 s in our live test)
Same-Cloud Recovery on SaladCloud (Salad to Salad)
Real SSH-Verified Recovery
Zero-Key Leakage Security
Unlimited SaladCloud Containers

Best Value • 2 Months Free

SpotWarp Annual Pass

Save 17% ($98/yr) with annual billing

$490 / year

⚡ Equivalent to $40.83 / month

Everything in Monthly Pass included
2 Months Free ($98 instant savings)
Continuous 365-day Auto-Protection
Zero-Key Leakage Security Guarantee
Unlimited SaladCloud Containers

Frequently Asked Questions

Got Questions? We Have Answers.

Everything you need to know about SpotWarp pricing, security, and failover protection.

One license protects unlimited SaladCloud container groups watched from that machine. A single SpotWarp Pass ($49/mo) provides continuous background backup and Same-Cloud failover for all of them. By default each protected container group also runs a second replica as a warm standby, which SaladCloud bills like any other replica. You can turn this off with --no-standby; recovery is then slower because SaladCloud has to allocate a new node.

No. The daemon runs on your own machine, not inside your GPU container, so it does not use your container's GPU. On Linux and macOS it copies only changed files with rsync, and it skips files that were written in the last 10 seconds so it does not copy a half-written checkpoint. On Windows it uses scp and copies the whole workspace each cycle.

Stop Losing Training Runs toSpot GPU Evictions