Finding the best VPS for AI tools comes down to one thing: whether the server has enough RAM, CPU, and storage to actually run what you install on it. A Linux VPS is a practical alternative to paying for a dedicated AI platform, especially when you want more control over your environment. Tools such as Ollama, AnythingLLM, n8n, and other self-hosted AI applications can run on a VPS, but the experience depends heavily on the server's RAM, CPU, storage, and overall resource allocation.
There are several VPS providers to choose from, and they do not all offer the same balance of price and resources. Hetzner, DigitalOcean, Vultr, Contabo, Verpex, Bluehost, and Akamai Cloud (Linode) all have different strengths depending on the workload. For example, Verpex offers Linux VPS plans with root access, dedicated resources, and NVMe storage, making it one of the options worth considering if you're looking for a lower-cost starting point. You can also see our Verpex review for our broader experience with the provider.
The important question, however, is not simply which provider is cheapest. An AI workload can quickly become limited by RAM or CPU, while local models also require enough storage for model files and containers. In this guide, we'll compare popular VPS options for AI tools, explain how much RAM and CPU you actually need, and show you how to set up and test a Linux VPS with tools such as Docker and Ollama.
What Actually Matters Before You Pick a VPS
AI workloads on a VPS split into two very different categories, and picking the wrong one wastes money either way. Know which one you're running before you look at a single plan.
- RAM, not CPU, is the first bottleneck. A quantized 7B model in Ollama needs roughly 6 to 8GB of RAM just to load. Anything under 8GB and you're limited to 1B to 3B models or API-connector tools like Langflow and AnythingLLM.
- AVX2/AVX-512 support matters for CPU inference. Run
lscpu | grep avxbefore you buy. Older shared-core plans sometimes disable these instruction sets, and llama.cpp based tools slow down badly without them. - NVMe storage over SATA SSD. Model files run 4 to 40GB each. Loading them off spinning disk or budget SSD adds real seconds to every cold start.
- Dedicated vCPU vs shared/burstable. Agent frameworks like CrewAI and n8n run multiple concurrent tasks. Shared vCPU plans throttle hard under that pattern.
- GPU is only required for local LLM inference at scale or image generation. If your tools call OpenAI, Claude, or Gemini APIs and just orchestrate the logic, a plain CPU VPS is fine and considerably cheaper.
| Model Size | Minimum RAM (Q4 quantized) | Recommended RAM |
|---|---|---|
| 1B to 3B | 2 to 3GB | 4GB |
| 7B to 8B | 6 to 8GB | 8 to 16GB |
| 13B | 10 to 12GB | 16GB |
| 30B to 34B | 20 to 24GB | 32GB |
| 70B | 40 to 48GB | 64GB or GPU offload |
These numbers assume Q4 quantization, the default most Ollama library tags ship as. Full-precision (unquantized) weights need roughly 3 to 4 times more RAM per parameter, which is one more reason quantized models are the practical default for VPS-based inference. See Ollama's official documentation for the current library and per-model file sizes before you size a server around a specific one.
If you're still deciding between hosting categories entirely, our shared hosting vs VPS vs cloud hosting breakdown covers where AI workloads fit compared to standard web hosting.
Best VPS for AI Tools: Provider Comparison
This table sorts by what each provider is actually good at, not by who pays the highest affiliate commission. Match the "best for" column to your workload before you look at price.
| Provider | Best For | AI-Ready Tier Price | RAM / vCPU (AI-ready tier) | GPU Available |
|---|---|---|---|---|
| Hetzner | CPU-heavy agents, Ollama on quantized models | ~€24.49/mo* | 16GB / 4 vCPU (dedicated, CCX23) | No |
| DigitalOcean | Docs, ecosystem, production n8n/LangChain deploys | ~$24.00/mo | 4GB / 2 vCPU | Yes (GPU Droplets) |
| Vultr | Fast global deploy, scalable Cloud GPU | ~$20.00/mo | 4GB / 2 vCPU | Yes (A100/L40S tiers) |
| Contabo | RAM-heavy multi-container stacks (Dify, RAG pipelines) | ~€4.50/mo | 8GB / 4 vCPU | No |
| Verpex | Budget-friendly root access with NVMe, good starter tier for testing agents before scaling | ~$7.19/mo | 4GB / 2 vCPU (NVMe) | No |
| Akamai Cloud (Linode) | Web scraping agents, Playwright/Selenium workloads | ~$24.00/mo | 4GB / 2 vCPU | Yes (higher tiers) |
For a broader look at general-purpose Linux VPS options outside the AI-specific angle, check our full best Linux VPS hosting roundup and the how to choose VPS hosting guide, which walks through the non-AI factors like data center location and support SLAs.
Prerequisites Before You Start
Have these ready before you SSH in. This is the minimum bar for running a self-hosted AI stack without fighting the server the whole time.
- A fresh Ubuntu 24.04 LTS or Rocky Linux 9 install, root or sudo access
- Minimum 4GB RAM for connector-based tools (n8n, AnythingLLM), 8GB+ for local model inference with Ollama
- At least 40GB free disk space, more if you plan to pull multiple models
- Port 11434 open if exposing Ollama's API externally, 3000 or 5678 for common web UIs (check your firewall rules)
- Docker Engine 29.x or newer, or the willingness to install it in Step 2 below
Step-by-Step: Validate a VPS Before You Commit To It
Run these checks in the first ten minutes of any trial period. It takes less time than reading a review, and it tells you the truth about the box you're actually paying for.
Step 1 - Check CPU, RAM, and AVX Support
This confirms the server actually has the resources and instruction sets the provider claims. Skip this and you're trusting a sales page.
LinuxTeck.com
nproc
# Confirm RAM total and available
free -h
# Confirm AVX2 / AVX-512 for faster CPU inference
lscpu | grep -i avx
Expected output: Four cores, at least 7GB usable RAM, and avx2 present in the flags line. If avx2 is missing, quantized model inference through llama.cpp based tools will run noticeably slower and you should look for a different plan or provider tier.
If free -h shows less than 4GB available on a fresh boot with nothing running, the provider is likely overselling that node. Cancel within the refund window and try a different plan.
Step 2 - Install Docker
Nearly every self-hosted AI tool, from n8n to Dify to Open WebUI, ships as a Docker container. Get the engine installed before you touch anything else. The commands below match Docker's official install documentation for both distro families.
On Ubuntu/Debian:
LinuxTeck.com
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
# Run docker without sudo every time
sudo usermod -aG docker $USER
On RHEL/Rocky Linux:
LinuxTeck.com
sudo dnf config-manager --addrepo https://download.docker.com/linux/centos/docker-ce.repo
sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker
Expected output: The docker.service unit shows active (running). Log out and back in once for the group change to apply, otherwise every docker command still needs sudo.
If you see permission denied while trying to connect to the Docker daemon socket, your shell session hasn't picked up the new group membership yet. Run newgrp docker or reconnect over SSH.
Step 3 - Pull and Run a Test Model With Ollama
This is the real stress test. If a small quantized model runs fine here, your box can handle most connector-based AI tools without issue.
LinuxTeck.com
curl -fsSL https://ollama.com/install.sh | sh
# Pull a small quantized model, good baseline test
ollama pull llama3.2:3b
# Send one test prompt and time the response
ollama run llama3.2:3b "Reply with OK if you are working"
Expected output: A short reply within 3 to 6 seconds on a 4 vCPU box with AVX2. If the pull finishes but the run command hangs for 20+ seconds before responding, the CPU is likely throttled or lacks the instruction sets the model needs for fast quantized inference.
If you see Error: model requires more system memory than is available, the plan doesn't have enough RAM headroom for even a 3B model. Move up a tier or switch to an API-connector tool instead of local inference.
Common Errors and Fixes
These four show up constantly in support forums and Discord servers once people move past the install step.
Container gets killed with exit code 137. This is the OOM killer, not a bug in the tool. Check dmesg | grep -i "out of memory" to confirm, then either add swap as a short-term fix or move to a plan with more RAM as the real fix. Swap will save you from a crash but it will not make inference fast.
Ollama API unreachable from your app container. By default Ollama binds to localhost only. Set OLLAMA_HOST=0.0.0.0 in the service environment so other containers on the same Docker network can reach it, then restrict access at the firewall level instead of the app level.
sudo ufw deny 11434 (or the matching firewalld rule) right after the change, or better, keep Ollama on a private Docker network bridge so containers reach it internally without touching the public interface at all.Disk fills up after pulling two or three models. Model files are large and Ollama keeps every version you've pulled. Run ollama list and ollama rm old ones you're not actively using, and check disk headroom with df -h before every new pull.
Docker Compose stack for tools like Dify won't start, Postgres exits immediately. This is almost always a RAM shortage during the multi-container startup, not a config error. Multi-service stacks with Postgres, Redis, and worker processes need 8GB minimum to boot cleanly, even if the idle footprint later drops.
Once things are running, keep an eye on resource usage with our htop command guide and the broader best Linux monitoring tools list so you catch a resource crunch before it kills a container mid-task.
Questions I Get Asked About This All the Time
Do I need a GPU VPS just to run n8n or AnythingLLM?
No. Those tools mostly orchestrate calls to external APIs or handle document parsing. A 4 to 8GB CPU-only VPS handles them fine. GPU only matters once you're running local model inference yourself.
How much RAM does Ollama actually need for a 7B model?
Budget 6 to 8GB for a Q4 quantized 7B model, plus 1 to 2GB overhead for the OS and any other containers running alongside it. A 16GB box gives you comfortable headroom to run two models or a model plus a full app stack.
Is a shared vCPU plan ever good enough for AI agents?
For light, occasional agent runs, yes. For anything running multiple concurrent tasks like a CrewAI crew or scheduled n8n workflows every few minutes, shared vCPU throttling shows up as inconsistent response times. Dedicated cores are worth the extra few dollars once you're past the testing phase.
Ubuntu or Rocky Linux for a self-hosted AI stack?
Either works. Ubuntu has broader out-of-the-box package availability for AI tooling and more community documentation. Rocky Linux is the better pick if you're already standardized on RHEL-family systems for compliance reasons. Our best Linux distro for AI comparison goes deeper on this.
Can I run these tools on a budget VPS under $10 a month?
Yes, for connector-based tools and small quantized models. We tested a 4GB NVMe plan from Verpex for this exact scenario and it handled AnythingLLM plus a 3B Ollama model without issue, though it's not the pick for running multiple agents at once.
What's the difference between an AI agent VPS and a normal one?
There isn't really a different product, it's the same VPS hardware. What changes is the sizing decision, RAM and dedicated CPU matter more for agent workloads than they do for a typical web server. See our AI agents for DevOps automation guide for how this plays out in real pipelines.
Do I need to harden the server differently for AI tools?
Yes, mainly around exposed ports. AI tool web UIs and APIs are newer software with less security scrutiny than something like nginx or SSH. Follow standard practices from our top Linux security tools list and never leave an inference API open without auth in front of it.
Should I use Docker Compose or install these tools bare metal on the VPS?
Docker Compose, almost always. Most AI tools ship official compose files, upgrades are a single pull and restart, and you avoid dependency conflicts between Python versions that different tools expect.
Final Take
You now know what actually matters, RAM first, AVX support second, dedicated CPU third, GPU only if you need real local inference. Run the three checks in Step 1 through 3 on any trial server before you commit to a year of billing.
Pick the best VPS for AI tools based on your actual workload, not the cheapest number on the page, and spin up a test box today. Thirty minutes of hands-on testing beats another hour of review reading.
Have you hit the OOM killer running Ollama on a small VPS, or found a provider that handled agent workloads better than expected? Drop it in the comments below. If this guide saved you a bad hosting decision, share it with someone about to make the same mistake.
This guide covered what actually decides whether a Linux VPS can run self-hosted AI tools, real provider comparisons, and step-by-step hardware validation.
LinuxTeck's Enterprise Linux category focuses on production-ready Linux skills including:
VPS hosting, self-hosted AI tools, Docker deployment, Ollama, server hardening, and Linux monitoring.
Thank you for reading and for being part of this journey. If this article saved you time, consider buying me a coffee. Every contribution helps me keep producing in-depth, practical Linux content for readers like you.
Thank you for your endless support
