Minimum

2GB RAM for a control-plane UI plus webhooks; 4 vCPU / 8GB if ffmpeg or several workers share the box.

Recommended

4 vCPU / 8GB RAM / 80GB+ NVMe for queue + transcode; buy disk and transfer before extra CPU.

Upgrade when

Upgrade disk and transfer first when staging files pile up. Move encode workers off the UI box when jobs queue overnight.

Who this page is for

This is for creators and small teams who already have a generation path — a hosted API, a rented GPU pod, or a desktop box — and need a VPS that stays up while jobs move through a queue.

  • Queue workers that download a source, call an API, run ffmpeg, then upload the result.
  • Object-storage caches and staging disks in front of S3, R2, or Backblaze B2.
  • Self-hosted UIs that submit jobs, poll status, and keep a thin history database.
  • Batch media chores that are not “AI”: concat, watermark, resize, transcode, thumbnails, subtitle burn-in.

If you came here because a listicle ranked “best GPU VPS for Sora-like video” on a $6 KVM, leave. VPSDoge will not invent that lab result.

CPU vs GPU, without the sales pitch

A normal cloud VPS has CPU. That is enough for Node or Python workers, Redis, Postgres, Caddy or Nginx, and ffmpeg with libx264 or libx265. It is not enough for local Wan, SVD, AnimateDiff, or a ComfyUI video graph at a speed anyone will wait for.

The usual honest split:

  • CPU VPS: 24/7 control plane. Cheap to leave on. Fine for queues and encode of already-generated files.
  • GPU API or short-lived GPU pod: the actual generation. You pay per minute or per job, then shut it down.
  • Big-RAM CPU box: helps concurrent ffmpeg and file buffers. It does not load a video diffusion model in any useful way.

If you later self-host the model, that is a different purchase — a GPU VPS or bare metal from a GPU specialist. Do not stretch a Hetzner CX32 into that job.

Updated Sep 12, 2026

SaladCloud repriced GPU hours at 00:00 UTC on 12 September 2026. That matters if your AI video batch actually generates frames on Salad. It does not change what a regular VPS is for.

Salad’s own customer post is the source — not a third-party screenshot, and not the host-earning chart (different numbers):

  • RTX 5090 and RTX 4090 High Priority went up. On Salad’s customer table, High Priority on the 5090 moved from $0.450 to $0.500 per GPU-hour; the 4090 from $0.300 to $0.330. Medium and Low on those two classes moved up with it. Lowest Priority on both stayed put ($0.250 / $0.160).
  • Fifteen other GPU classes got cheaper — Salad says about 25% on average at High Priority, with individual cuts between 16% and 38%. Lowest Priority is mostly unchanged, except the RTX 5080 Lowest drop ($0.180 → $0.150). Mid-range 50-series and last-gen 40/30 cards are in that cheaper set.
  • CPU-only vCPU hours also ticked up ($0.004 → $0.005). RAM is unchanged. GPU container groups are not billed for vCPU or RAM.

Read the full previous → new table on Salad’s September 12, 2026 price-change post. Live list prices sit on salad.com/pricing. A separate node-earning post is for hosts, not your rental bill — do not mix the two charts.

Salad GPU cloud vs a dedicated VPS for batch video: keep the split this page already uses. Salad is GPU minutes. A VPS is the always-on control plane.

  • Salad GPU cloud: pay per hour, pick a priority tier, generate frames, shut it down. High Priority costs more and is the tier that just got more expensive on 5090/4090. Lowest Priority is cheaper and already where Salad competes hardest — and those two flagship Lowest rates did not move. Fine for overnight or interruptible batch. Not a box you leave running a queue, Redis, and a UI for $6/month.
  • Dedicated CPU VPS: the Hetzner / Vultr / Contabo shapes below. Cheap to leave on. ffmpeg, caches, webhooks. It will not load Wan or a ComfyUI video graph at a speed anyone waits for, and this Salad reprice does not change that.

If your graph needs a 5090 or 4090 on High Priority, the September 12 bill is a bit higher — still rent the GPU, still keep the VPS. If a 5080, 4070-class, or 3090 is enough, Salad just made that path cheaper. Either way: do not buy a “GPU VPS” story on a regular KVM, and do not try to replace the control-plane VPS with Salad hours.

Bandwidth and storage decide the bill

Video files are large. A few hundred 1080p clips, plus retries, proxies, and thumbnails, will empty a 2TB transfer cap faster than they pin four vCPUs. Read the overage rule. “Unlimited” often means a shared 100–200Mbps port that collapses when you push overnight jobs.

  • Keep the working set on NVMe. Push finals to object storage. Do not treat the VPS disk as the archive.
  • Size disk for at least two generations of in-flight jobs, not only today’s folder.
  • Put the cache close to the encoder or close to users — not on a CN2 GIA plan you bought for a China-facing brochure site.

Recommended plan shapes

Use providers already on VPSDoge. Pick the shape, then the logo.

Shape Start here What it should do Providers already on this site
Control plane 2 vCPU / 2-4GB RAM / 40-80GB SSD Webhook UI, Redis, job API, a reverse proxy. No local encode. Hetzner CX22, Vultr 2-4GB, DigitalOcean Basic 2-4GB, Linode 2-4GB
Batch worker 4 vCPU / 8GB RAM / 80-160GB NVMe ffmpeg, queue concurrency, thumbnail and concat jobs overnight. Hetzner CX32 / CX33, Vultr High Frequency 4-8GB, Contabo Cloud VPS S
Cache / staging 1-2 vCPU / 2-4GB RAM / large disk + clear transfer MinIO, rclone, nginx cache in front of R2 or S3. Working-set files only. HostHatch storage VPS, Contabo disk-heavy plans, Hetzner with extra volume
  • Hetzner — consistent CPU for Europe-based workers. CX32 / CX33 is the useful encode floor.
  • Vultr — High Frequency when you want hourly tests in a specific region.
  • Contabo — RAM and staging disk per euro. IO can wobble; keep databases light.
  • HostHatch — transfer and disk for caches, not for pretty single-core encode.
  • DigitalOcean or Linode — the control-plane UI if you want docs more than raw CPU.

Do not buy this: Tiny yearly 1GB plans, "unlimited" transfer with a 100Mbps cap, and any regular VPS sold as a local video-generation GPU.

Related VPS jobs on the same site

A video pipeline is usually one piece of a small stack. The control-plane box looks a lot like an early SaaS backend: API, database, workers, reverse proxy. Size the whole stack, not the “AI” label.

If the product emails job results or login codes, that is a different constraint. Self-hosted mail wants a clean IP, open port 25, and spare RAM — see the Mailcow VPS guide. Do not share that box with overnight ffmpeg.

Prompt labs and other tool sites still need a boring VPS for side services: accounts, rate limits, queues, file staging, and outbound mail. The generator can live on an API. The site still needs a server you can restore.

Same pattern as Docker apps and n8n: count Redis, Postgres, logs, and failed-job retries before you celebrate the $4 plan. Keep an offsite backup VPS if the queue database matters.

AI video VPS FAQ

Can a regular VPS generate AI video locally?
No, not at a useful quality or speed. Local diffusion video, Wan, SVD, and ComfyUI video graphs need a GPU. A regular VPS is the always-on control plane: queues, webhooks, ffmpeg, caches, and a small UI that calls a GPU API or a rented GPU elsewhere.
Do I need a GPU VPS for an AI video pipeline?
Only if you will run the model yourself. If you already buy Runway, Kling, Luma, Fal, Replicate, or a short-lived GPU pod, keep that spend there and put the boring 24/7 pieces on a CPU VPS. Do not buy a 32GB CPU box hoping it "kind of" generates video.
What matters more than CPU for batch media?
Disk and monthly transfer. A few hundred 1080p clips plus retries and thumbnails will burn a 2TB cap faster than they saturate four vCPUs. Size NVMe for the working set, push finals to object storage, and read the overage rules before you buy.
Is 2GB RAM enough for an AI video VPS?
2GB is enough for a webhook UI, Redis, and a single light worker. Use 8GB when ffmpeg, several queue workers, or a database share the same VPS. RAM helps buffers and concurrency. It does not replace a GPU.
Hetzner, Contabo, or HostHatch for this workload?
Hetzner if you want consistent CPU for ffmpeg workers in Europe. Contabo if you need RAM and staging disk on a budget and can live with uneven IO. HostHatch if the job is cache, sync, or a high-transfer object-store frontend rather than encode.
Can I run this next to a small SaaS or self-hosted email?
A control-plane box can share a 4GB VPS with a small API. Do not put Mailcow and overnight ffmpeg on the same 8GB host. Email wants a clean IP and spare RAM; batch media wants disk and transfer. Split them when either job matters.