Migrate from Salad Cloud to Vast.ai - Vast.ai Documentation: Affordable GPU Cloud Marketplace

A guide for users moving GPU workloads from Salad Cloud to Vast.ai. Whether you use Salad’s Container Engine for long-running containers or Job Queues for autoscaling inference, this guide maps every concept to its Vast.ai equivalent and walks you through the transition. What is different: In a nutshell, you have more control. You choose your specific machine, see the exact specs you are getting, and set the reliability level you need, rather than relying on an opaque allocation. You also get direct SSH access, persistent storage, and datacenter-grade GPUs alongside consumer hardware. This guide addresses each of these differences head-on so there are no surprises.

What Salad Cloud users need to know about Vast.ai:

Your existing Docker images work as-is. Salad requires AMD64/Linux containers — the same format Vast uses. No rebuilds needed, and there’s no image size limit (Salad caps at 35GB compressed).
Persistent storage that survives restarts. Stop an instance and resume later with all your data — models, checkpoints, datasets — still there. Plus built-in Cloud Sync to S3, Google Drive, Backblaze, and Dropbox.
Consumer and datacenter GPUs, including multi-GPU. Access A100s, H100s, and multi-GPU configurations alongside the same consumer GPUs you use today — unlocking workloads that need more than 32GB VRAM or more than one GPU.
Full visibility into every machine before you rent. Each offer shows reliability score, network speed, CPU specs, and location, so you can pick the exact machine that fits your workload.
Reserved instances for up to 50% savings. Lock in discounted rates for long-running workloads — a pricing option not available on Salad.
Direct SSH, built-in Jupyter, and up to 64 ports. Key-based SSH, Jupyter with TLS, VS Code Remote-SSH, and multi-port support — all out of the box.

In This Guide

Concept Mapping: Salad terms → Vast equivalents
Account Setup
Migrating from Container Engine: instances, Docker config, storage, networking, SSH, logs, lifecycle/cost
Migrating from Job Queues: autoscaling inference with Vast Serverless
Command Reference: side-by-side command table

Concept Mapping

Salad and Vast use different names for similar concepts. The rest of the guide covers each in detail.

Salad Cloud	Vast.ai	Notes
Container Group (SCE)	Instance	A container group manages multiple replicas; each Vast instance is one machine. See Finding and Creating Instances
Job Queue	Serverless Endpoint → Workergroup → Worker	Managed autoscaling inference. See Migrating from Job Queues
Recipe	Template	Pre-configured Docker environments
Salad Simple Storage (S4)	Cloud Sync (S3, Google Drive, Backblaze, Dropbox)	S4 is a managed temporary store (100MB, 30-day expiry). Cloud Sync transfers data between your instance and your own cloud storage. See Storage
Container Gateway	Instance Portal / direct port access	Salad: one port, managed URL. Vast: up to 64 ports with Cloudflare tunnels or direct IP
Priority (high/medium/low/batch)	Instance type (on-demand / interruptible / reserved)	See On-Demand vs Interruptible

Account Setup

Create an account at cloud.vast.ai
Add credits. Vast is prepaid. Add funds via the Billing page before renting.
Add your SSH public key at cloud.vast.ai/manage-keys/. If you do not have one, generate it with ssh-keygen -t ed25519. This enables direct SSH access to your instances with key-based authentication, Jupyter, and VS Code Remote-SSH support.

That’s all you need to get started via the console. If you plan to use the CLI or REST API, also:

Generate an API key at API Keys and authenticate:

Vast CLI

pip install vastai
vastai set api-key <YOUR_API_KEY>

Migrating from Container Engine

Salad’s Container Engine (SCE) deploys Docker containers across a distributed fleet of GPUs, primarily consumer-grade. You specify hardware requirements (vCPUs, RAM, GPU model) and Salad allocates nodes from its network. The Vast.ai equivalent is an Instance: also a Docker container with exclusive GPU access, but rented from an open marketplace where you choose the exact machine. The core workflow is the same (pick a GPU, choose an image, launch), but how you find that GPU is different.

Finding and Creating Instances

On Salad, you specify hardware requirements and the platform allocates available nodes. On Vast.ai, you search a marketplace of available offers with full transparency into each machine’s specs, reliability, network speed, and location — then choose the one that best fits your workload. Always check these before renting:

Reliability score: historical uptime percentage. Look for 0.95+ for production workloads. If reliability is critical, filter for Secure Cloud machines only.
Network speed: inet_down and inet_up in Mbps. Matters for model downloads and data transfer.
Geolocation: filter by region for latency-sensitive workloads, similar to Salad’s country-level targeting.

Console
API/CLI

Go to Search
Use the GPU type, VRAM, reliability, and region filters to narrow results
Review each offer’s reliability score and network speed before renting
Click Rent on your chosen offer and configure image, disk, and Docker options in the dialog

curl -X POST "https://api.salad.com/api/public/organizations/$ORG/projects/$PROJECT/containers" \
    -H "Salad-Api-Key: $API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
        "name": "my-workload",
        "container": {
            "image": "your-image:latest",
            "resources": {
                "cpu": 4,
                "memory": 16384,
                "gpu_classes": ["<GPU_CLASS_ID>"]
            }
        },
        "replicas": 1
    }'

Common GPU searches:

Vast CLI

# RTX 4090 (24GB) -- popular for inference
vastai search offers 'gpu_name = RTX_4090' --order "dph_base" --limit 5

# Multi-GPU for distributed training. Note: gpu_ram is per-GPU, not total --
# this query matches 4+ GPUs with at least 80 GB each (e.g., 4x A100/H100 80GB).
vastai search offers 'num_gpus >= 4 gpu_ram >= 80' --order "dph_base" --limit 5

# US only (similar to Salad's country targeting)
vastai search offers 'gpu_ram >= 24 geolocation = US' --order "dph_base" --limit 10

Multiple GPU types. On Salad, a container group can specify multiple GPU classes (e.g., RTX 4090 and RTX 3090) and the platform assigns the first available one. On Vast, you can achieve similar flexibility by searching for offers across multiple GPU types (e.g., gpu_name in ["RTX_4090","RTX_3090"]) and creating instances from any matching offer, or by using Vast Serverless which automatically selects the best GPU for your workload.

Docker Environment

Images

Your existing Salad Docker images work on Vast with no modification. Salad requires AMD64/Linux containers — the same format Vast uses. Just specify the image in the --image flag. To minimize cold start times:

Use Vast base images (also on DockerHub), which are pre-cached on many hosts
Use smaller, optimized images where possible
For very large images, build on top of a pre-cached base

Set your disk size right at launch. Resizing disk requires recreating the container. Storage is cheap, so err on the side of more space — especially if you plan to download large models or datasets after launch.

Environment Variables

On Salad, environment variables are set in the portal or passed via the API when creating a container group. Vast works the same way.

Console
API/CLI

In the instance creation dialog or template editor, set environment variables using the GUI fields or the Docker Options field with Docker syntax:

-e HF_TOKEN=hf_xxxxx -e MODEL_NAME=meta-llama/Llama-3-8B

curl -X POST "https://api.salad.com/api/public/organizations/$ORG/projects/$PROJECT/containers" \
    -H "Salad-Api-Key: $API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
        "name": "my-workload",
        "container": {
            "image": "your-image:latest",
            "resources": {
                "cpu": 4,
                "memory": 16384,
                "gpu_classes": ["<GPU_CLASS_ID>"]
            },
            "environment_variables": {
                "HF_TOKEN": "hf_xxxxx",
                "MODEL_NAME": "meta-llama/Llama-3-8B"
            }
        }
    }'

The Vast CLI --env flag takes raw Docker run options, not just KEY=VALUE pairs. Port mappings go here too, for example: --env "-e MY_VAR=foo -p 8080:8080".

Entrypoint Arguments

On Salad, the container command is configured in the container group settings. On Vast, use --args:

Console
API/CLI

In the template editor or instance creation dialog, enter entrypoint arguments in the Docker Options field.

curl -X POST "https://api.salad.com/api/public/organizations/$ORG/projects/$PROJECT/containers" \
    -H "Salad-Api-Key: $API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
        "name": "vllm-server",
        "container": {
            "image": "vllm/vllm-openai:latest",
            "resources": {
                "cpu": 4,
                "memory": 16384,
                "gpu_classes": ["<GPU_CLASS_ID>"]
            },
            "command": ["--model", "Qwen/Qwen2.5-7B-Instruct", "--max-model-len", "4096"]
        },
        "networking": {
            "protocol": "http",
            "port": 8000
        }
    }'

Use --args when your image’s entrypoint already accepts the flags you need (as vLLM does here). For anything more complex — pip installs, multi-step boot, conditional launch — use --onstart-cmd instead (see Startup Scripts below). The two are not interchangeable: --args replaces the container CMD; --onstart-cmd runs alongside it.

Startup Scripts

Vast has an on-start script that runs a shell command after the container starts — useful for installing dependencies, pulling model weights, or starting services without modifying your Docker image. Salad has no equivalent.

Console
API/CLI

In the template editor or instance creation dialog, enter your startup commands in the On-start Script field.

# No equivalent -- Salad does not support on-start scripts
# Use your Docker entrypoint or CMD instead

Once you have a working configuration, save it as a reusable Vast template in the console. See the Templates guide for details.

Storage

Salad provides only ephemeral container storage — all data is lost when a container is reallocated. Vast gives you multiple storage tiers:

Container storage: Temporary, same as Salad. Deleted when the instance is destroyed.
Persistent volumes: Local storage that survives container restarts on the same machine. Ideal for model weights, datasets, and training checkpoints.
Cloud Sync: Vast’s built-in sync tool supports S3, Google Drive, Backblaze, and Dropbox. Access it via the console or vastai cloud copy.

For model weights and datasets, the recommended approach is to pull from object storage on boot. This works across any host and keeps your instance stateless.

Console
API/CLI

Use the Cloud Sync button on the instance card to configure transfers between your instance and cloud storage. Set up your cloud connection on the Account page first.

# No equivalent -- Salad provides only ephemeral storage
# Use S4 (100MB limit, 30-day expiry) or external object storage

Vast local volumes are tied to the physical machine they were created on. For data that needs to persist across different hosts, use cloud object storage (S3, R2, GCS) via Vast’s built-in Cloud Sync.

Networking and Ports

On Salad, the Container Gateway provides a managed URL with load balancing for one inbound HTTP/HTTPS port. On Vast, there are two proxy mechanisms:

HTTP/HTTPS proxy: Instances using Vast base images get auto-generated Cloudflare tunnel URLs (https://four-random-words.trycloudflare.com) per open port via the Instance Portal.
SSH proxy: Instances using SSH-compatible images support proxy SSH through Vast’s proxy server, which works even on machines without open ports.

Instances also have direct access via a random external port on the host’s public IP, which you discover after launch.

Declaring Ports at Launch

Console
API/CLI

In the instance creation dialog or template editor, enter port mappings in the Docker Options field:

-p 8000:8000 -p 8080:8080

# Container Gateway exposes one port per container group
curl -X POST "https://api.salad.com/api/public/organizations/$ORG/projects/$PROJECT/containers" \
    -H "Salad-Api-Key: $API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
        "name": "my-workload",
        "container": {
            "image": "your-image:latest",
            "resources": {
                "cpu": 4,
                "memory": 16384,
                "gpu_classes": ["<GPU_CLASS_ID>"]
            }
        },
        "networking": {
            "protocol": "http",
            "port": 8000,
            "auth": false
        }
    }'

Limits: Maximum 64 open ports per container. For a stable external port number, use internal ports above 70000, which are identity-mapped (the external port matches the internal port).

Discovering Your External Port

Console
API/CLI

After the instance starts, click the Open Ports button on the instance card to see the external port mapping.

# Container Gateway provides a static URL with a random subdomain
# e.g., https://tomato-navybean-pm82t0txwjyus8yy.salad.cloud
# No port discovery needed -- Gateway maps to your configured port

Vast also sets VAST_TCP_PORT_<N> environment variables inside the container for each mapped port. Use these in your application code to construct external URLs.

Connecting to Your Instance

SSH

On Salad, you get SSH connection details from the portal. On Vast, SSH uses key-only authentication (make sure you’ve added your public key in Account Setup).

Console
API/CLI

Click the SSH button on the instance card to see the full connection command, then paste it into your terminal.

# SSH connection details from Portal
# Portal > Container Group > Instances > SSH button
ssh root@<hostname> -p <port>

Instances using Vast base images connect to a tmux session by default. Use Ctrl+B C to open a new window and Ctrl+B N to cycle between windows. To disable tmux, create ~/.no_auto_tmux inside the container. Port forwarding works the same as any SSH connection:

ssh -p <PORT> root@<VAST_IP> -L 8080:localhost:8080

Jupyter / IDE Access

Jupyter is available out of the box on Vast with two access modes:

Proxy mode (default): Click the Jupyter button in the Vast console. Works immediately, no setup needed.
Direct HTTPS (recommended): Faster, more reliable connection that bypasses the proxy. Instances using Vast base images include a built-in Jupyter TLS certificate. Install the Vast TLS root certificate (jvastai_root.cer), downloadable from the Vast console, to connect directly over HTTPS without browser warnings.

Both VS Code and Cursor are supported via Remote-SSH.

Logs

Console
API/CLI

Click the Logs button on the instance card to view live output.

curl -X POST "https://api.salad.com/api/public/organizations/$ORG/log-entries" \
    -H "Salad-Api-Key: $API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
        "project_name": "my-project",
        "container_group_name": "my-workload"
    }'

Vast logs may take a short time to become available after an instance starts. If you see “waiting on logs” messages, retry after a moment.

Instance Lifecycle and Cost

Start, Stop, and Destroy

Console
API/CLI

Use the buttons on the instance card: Stop to pause compute, Destroy to delete the instance and stop all charges.

# Stop container group
curl -X POST "https://api.salad.com/api/public/organizations/$ORG/projects/$PROJECT/containers/$GROUP_NAME/stop" \
    -H "Salad-Api-Key: $API_KEY"

# Delete container group
curl -X DELETE "https://api.salad.com/api/public/organizations/$ORG/projects/$PROJECT/containers/$GROUP_NAME" \
    -H "Salad-Api-Key: $API_KEY"

On Vast, stopped instances retain their data — unlike Salad, where stopping a container group loses everything:

Vast Action	Compute Charges	Storage Charges	Data Preserved
Stop	Stop	Continue	Yes
Destroy	Stop	Stop	No

If you are done with an instance, destroy it. Stopped instances continue to cost money for storage. Only stop instances you plan to resume soon.

On-Demand vs Interruptible

Salad uses a priority tier system (High, Medium, Low, Batch) where higher-priority workloads can preempt lower-priority ones. Vast uses a similar model:

Vast Type	Salad Equivalent	Price	Interruption Risk
On-Demand	High priority	Standard marketplace rate	None (guaranteed)
Interruptible	Low / Batch priority	Often significantly cheaper	Can be displaced by on-demand renters

Console
API/CLI

On the Search page, use the Instance Type toggle to switch between on-demand and interruptible offers before renting.

# Priority set on the container object
# "priority": "high" | "medium" | "low" | "batch"
curl -X POST "https://api.salad.com/api/public/organizations/$ORG/projects/$PROJECT/containers" \
    -H "Salad-Api-Key: $API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
        "name": "my-workload",
        "container": {
            "image": "your-image:latest",
            "resources": {
                "cpu": 4,
                "memory": 16384,
                "gpu_classes": ["<GPU_CLASS_ID>"]
            },
            "priority": "high"
        },
        "autostart_policy": true,
        "restart_policy": "always",
        "replicas": 1
    }'

Use interruptible instances for batch inference, training with checkpointing, or any workload that can be restarted if interrupted. Save checkpoints frequently.

Reserved Instances

Salad has no equivalent to reserved instances. On Vast, if you run an on-demand instance for days or weeks, convert it to a reserved instance for up to 50% savings. Reserved instances lock in a discounted rate in exchange for a time commitment.

Console
API/CLI

Not all machines support reserved pricing. To find eligible machines, go to Search and switch the On-demand filter to Reserved. After renting, click the green discount badge on your instance card to open the pre-payment dialog.

# No equivalent -- Salad does not offer reserved pricing

Migrating from Job Queues

Salad Job Queues let you distribute discrete tasks across container replicas — you push work items to a queue, and Salad distributes them across nodes with auto-retry (up to 3 retries) and autoscaling up to 500 replicas. Vast Serverless is request-based rather than queue-based: you send requests to an endpoint, and Vast routes them to autoscaling workers. The key difference is that you don’t manage a queue — Vast handles routing, queueing, and scaling automatically. Pricing: Serverless workers run on the same marketplace instances you’d rent directly — you pay the same per-second rate, just with autoscaling on top.

Vast Serverless Architecture

Component	Purpose
Endpoint	Routes requests, manages autoscaling
Workergroup	Defines what code runs and how workers are recruited
Worker	Individual GPU instance running your model via PyWorker

Deployment Options

PyWorker (Custom Handlers) is the core framework for building serverless workers. You implement a handler function in Python, with full control over request preprocessing, model loading, and response formatting. Most production deployments use custom PyWorker handlers. See the PyWorker documentation to get started. Pre-built Templates serve as ready-to-use starting points. Vast provides templates for common frameworks (vLLM, TGI, ComfyUI) that you can deploy directly or use as a reference for building your own handlers.

Creating Endpoints and Workergroups

Console
API/CLI

Go to Serverless in the console
Click New Endpoint and configure name, max workers, and scaling parameters
Add a workergroup: choose a pre-built template for quick setup, or configure a custom PyWorker by specifying your Docker image and PYWORKER_REPO environment variable

# Step 1: Create a Job Queue
curl -X POST "https://api.salad.com/api/public/organizations/$ORG/projects/$PROJECT/queues" \
    -H "Salad-Api-Key: $API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
        "name": "my-llm-queue",
        "display_name": "My LLM Queue",
        "description": "LLM inference queue"
    }'

# Step 2: Create a container group connected to the queue
curl -X POST "https://api.salad.com/api/public/organizations/$ORG/projects/$PROJECT/containers" \
    -H "Salad-Api-Key: $API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
        "name": "my-llm-workers",
        "container": {
            "image": "your-worker-image:latest",
            "resources": {
                "cpu": 4,
                "memory": 16384,
                "gpu_classes": ["<GPU_CLASS_ID>"]
            }
        },
        "replicas": 3,
        "queue_connection": {
            "path": "/",
            "port": 8000,
            "queue_name": "my-llm-queue"
        }
    }'

Calling Your Endpoint

import requests

# Submit a job to the queue
response = requests.post(
    "https://api.salad.com/api/public/organizations/your-org/projects/your-project/queues/my-llm-queue/jobs",
    headers={"Salad-Api-Key": "YOUR_API_KEY"},
    json={"input": {"prompt": "Explain quantum computing in simple terms"}}
)
job = response.json()
print(job["id"])

Command Reference

Task	Salad API	Vast CLI
Authenticate	`Salad-Api-Key` header	`vastai set api-key <KEY>`
Create	`POST /organizations/{org}/projects/{proj}/containers`	`vastai create instance <ID> --image img`
List	`GET /organizations/{org}/projects/{proj}/containers`	`vastai show instances`
Show	`GET /organizations/{org}/projects/{proj}/containers/{id}`	`vastai show instance <ID>`
Start	`POST /organizations/{org}/projects/{proj}/containers/{name}/start`	`vastai start instance <ID>`
Stop	`POST /organizations/{org}/projects/{proj}/containers/{name}/stop`	`vastai stop instance <ID>`
Delete	`DELETE /organizations/{org}/projects/{proj}/containers/{id}`	`vastai destroy instance <ID>`
Logs	`POST /organizations/{org}/log-entries`	`vastai logs <ID>`
SSH	Portal SSH + web terminal	`vastai ssh-url <ID>`
Search GPUs	(not available)	`vastai search offers '<FILTERS>'`
Serverless	(Job Queues via API)	`vastai create endpoint --endpoint_name "x"`
Cloud sync	(S4 or DIY)	`vastai cloud copy`
Reserve	(not available)	`vastai prepay instance <ID> <AMOUNT>`

For programmatic usage, the Vast CLI supports --raw for JSON output that can be parsed in scripts. See the CLI Reference for full documentation.

Next Steps

CLI Reference: full command reference for the vastai CLI
Templates: save your configuration as a reusable template
Storage Types: persistent volumes, cloud sync, and data movement
Finding & Renting Instances: marketplace filters, reliability scores, and offer details

AI/ML frameworks

Serving infrastructure

Migration guides

AI agents

MCP

Text generation

Image generation

Video generation

Audio & transcription

Information extraction

Serverless deployments

Templates

Virtual desktops & VMs

Graphics & GPU programming

Other

Documentation Index

​In This Guide

​Concept Mapping

​Account Setup

​Migrating from Container Engine

​Finding and Creating Instances

​Docker Environment

​Images

​Environment Variables

​Entrypoint Arguments

​Startup Scripts

​Storage

​Networking and Ports

​Declaring Ports at Launch

​Discovering Your External Port

​Connecting to Your Instance

​SSH

​Jupyter / IDE Access

​Logs

​Instance Lifecycle and Cost

​Start, Stop, and Destroy

​On-Demand vs Interruptible

​Reserved Instances

​Migrating from Job Queues

​Vast Serverless Architecture

​Deployment Options

​Creating Endpoints and Workergroups

​Calling Your Endpoint

​Command Reference

​Next Steps

In This Guide

Concept Mapping

Account Setup

Migrating from Container Engine

Finding and Creating Instances

Docker Environment

Images

Environment Variables

Entrypoint Arguments

Startup Scripts

Storage

Networking and Ports

Declaring Ports at Launch

Discovering Your External Port

Connecting to Your Instance

SSH

Jupyter / IDE Access

Logs

Instance Lifecycle and Cost

Start, Stop, and Destroy

On-Demand vs Interruptible

Reserved Instances

Migrating from Job Queues

Vast Serverless Architecture

Deployment Options

Creating Endpoints and Workergroups

Calling Your Endpoint

Command Reference

Next Steps