Best VPS for Ollama: Self-Host Local LLMs in 2026

If you've searched for this, you've probably already noticed something: most "best hosting for Ollama" content reads like it was written by someone who has never actually run Ollama on a rented server. It lists providers, pastes in generic VPS specs, and never mentions the one thing that determines whether your setup is actually usable — the fact that almost no consumer VPS comes with a GPU.

That single detail changes everything about how you should approach this. So before any provider comparison, let's get the mental model right.

Quick answer: what you actually need

A VPS can absolutely run Ollama. What it usually can't do is run it fast, because standard VPS plans give you vCPU cores and RAM, not a GPU. Ollama runs inference on the CPU by default when no GPU is available, and CPU inference is dramatically slower than GPU inference — often the difference between a snappy chat response and watching text crawl out one word at a time.

That means the real question isn't "which VPS is best for Ollama" in the abstract. It's: which model size do you actually need, and does a CPU-only box deliver acceptable speed for that model? For small models (3B–8B parameters), the answer is often yes. For anything bigger, a standard VPS becomes a bad fit unless you specifically rent a GPU-equipped instance, which is a different (and pricier) product category entirely.

Why self-host Ollama on a VPS at all

Before the sizing math, it's worth being clear on the actual use cases, because they shape which plan makes sense:

• Privacy-sensitive workflows — internal tools, client data, or automations where sending prompts to a third-party API isn't acceptable.
• Predictable costs — a fixed monthly VPS bill instead of per-token API pricing that scales with usage.
• Background automation — connecting Ollama to something like n8n or a custom script where responses don't need to be instant, just correct.
• Learning and experimentation — running your own model server without buying a GPU workstation.

If your use case is "I want ChatGPT-speed responses for a customer-facing app," a VPS running Ollama on CPU is the wrong tool. If it's "I want a private, always-on model I can hit from my own scripts and don't mind a few seconds of latency," a VPS is a genuinely good fit.

Model size vs. hardware: the table that actually matters

Ollama's own resource footprint is negligible — it's the model you load that determines everything. Models on Ollama's library default to 4-bit quantization, and a reliable rule of thumb is roughly 0.6 GB of RAM per billion parameters at that quantization level, plus overhead for context and the OS.

A practical buffer rule: whatever the model's download size is, plan for system RAM at least 4–8 GB above that, since the OS, Ollama itself, and any concurrent process all need headroom. If you plan to keep more than one model loaded at a time, multiply accordingly — Ollama keeps a loaded model resident in memory for as long as it's active; it doesn't free RAM between requests the way a typical web app would.

Sizing your VPS: a straightforward decision path

Rather than picking a provider first and hoping the specs work out, work backward from the model:

1. Decide the smallest model that does your job well. Don't default to the biggest model you've heard of — a well-prompted 8B model handles a lot of real automation and internal-tool use cases just fine.
2. Add your RAM buffer. Take the model's approximate RAM need from the table above and add 4–8 GB.
3. Match vCPU cores to your latency tolerance. More cores mostly help with concurrent requests, not per-request speed — a single conversation doesn't get dramatically faster by adding cores past 4, but running Ollama alongside other services (a database, n8n, a reverse proxy) does benefit from extra cores.
4. Check disk space separately from RAM. Model files range from roughly 2 GB (small quantized models) to 20+ GB for larger ones, and you'll likely want to keep two or three around while testing. Budget at least 60–100 GB of NVMe storage if you plan to experiment.
5. If you genuinely need a 30B+ model, stop shopping for a "VPS" and start shopping for a GPU cloud instance. This is a different product line even at the same providers, and pretending otherwise is how people end up disappointed.

Provider comparison: what's actually worth paying for

These are general-purpose, non-GPU VPS/cloud plans suitable for the 3B–14B range described above. Specs and pricing in this market change often — treat the numbers below as a snapshot at the time of writing, and confirm current pricing before buying.

Getting Ollama running: the short version

This roundup isn't the full tutorial — that's a dedicated step-by-step post — but here's the shape of it so you know what you're signing up for:

1. Spin up an Ubuntu-based VPS (22.04 or 24.04 LTS are the safest choices for compatibility).
2. SSH in, update the system, and install Ollama with its official install script.
3. Pull a model sized to your RAM (ollama pull llama3.1:8b, for example).
4. Decide how you'll access it: locally via SSH tunnel for testing, or exposed through a reverse proxy with authentication if you want to hit it from other apps.
5. Set up basic monitoring for RAM usage — this is the resource you'll hit a ceiling on first, not disk or bandwidth.

That's the full shape of it, but a from-scratch server setup has a lot of places to get wrong — firewall rules, reverse proxy config, auth. We've written up the complete walkthrough separately, command by command.

If you'd rather not run through it solo, our team sets this up for clients regularly.

Security considerations people skip

This is the part most "best hosting for Ollama" content leaves out entirely, and it's the part that actually matters once your server is reachable from the internet:

• Never expose Ollama's default API port directly to the internet without authentication. Ollama's API has no built-in auth layer by default — anyone who finds the port can send it requests and burn your CPU.
• Put it behind a reverse proxy (Nginx or Caddy) with basic auth or an API key check, especially if you're calling it from external tools like n8n.
• Use your provider's firewall, not just the OS firewall. Hostinger's hPanel, for example, includes a network-level firewall you configure outside the VM itself — that's a second layer that survives even if something on the server gets misconfigured.
• Keep the OS patched. Whichever provider you choose, the hypervisor and physical security are on them — everything above that, including security updates, is on you.

Beginner mistakes worth avoiding

• Picking a model size based on hype, not fit. People grab a 32B model "because it's smarter" and then wonder why every response takes two minutes on a CPU-only box.
• Forgetting that Ollama keeps models loaded in memory. Loading three different models across a session without unloading them can exhaust RAM even on a plan that looked generous on paper.
• Assuming a bigger vCPU count fixes single-request slowness. Inference on a single request is mostly bottlenecked at the model level; more cores help concurrency, not the speed of one conversation.
• Skipping the reverse proxy step because "it's just for testing." Testing servers get scanned and probed too — this isn't a step to skip just because you don't consider it production yet.
• Not checking renewal pricing. Several budget VPS providers show attractive intro pricing that increases meaningfully at renewal — factor that into any long-term cost comparison, not just the first invoice.

Cost expectations

For the 7B–13B range most self-hosters actually use, expect to land somewhere in the $8–$30/month range for a capable non-GPU VPS, depending on provider, plan tier, and term length. That's meaningfully cheaper than a lot of pay-per-token API usage for a moderate, steady workload — but remember you're trading a metered cost for a fixed one, which only pays off if you're actually using the server regularly.

If your workload genuinely needs GPU-accelerated inference for larger models, budget for a different category of instance entirely — GPU cloud pricing is a separate conversation from standard VPS pricing, and comparing the two directly isn't a fair comparison.

Where this fits if you need help

If you're running a business site already and want an internal AI tool without sending sensitive data through a third-party API, this is exactly the kind of infrastructure decision CODEWITHMS handles for clients — sizing the server correctly the first time instead of over- or under-provisioning. If you're doing this as a personal project, the steps above should get you most of the way there on your own.