Free tools Windows power users keep installed
One-click scans. No signup required.
Install Ollama on a Linux VPS with the official installer, run ollama serve under a dedicated systemd service, and keep model files on a persistent disk sized for your chosen models. Manage models with the pull, run, list, show, ps, stop, and rm commands. Ollama listens on 127.0.0.1:11434 by default, so expose it remotely only through an authenticated reverse proxy, private network, or SSH tunnel.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
This setup works well for game-server tooling, offline NPC experiments, dialogue prototypes, moderation helpers, and development utilities. The VPS still needs enough RAM, VRAM, disk capacity, and I/O for the model and its context window; there is no single universal VPS size that fits every Ollama model.
As an Amazon Associate I earn from qualifying purchases.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsWhat an Ollama VPS deployment actually contains
An Ollama deployment has four separable parts:
- The Ollama binary: the program that serves models and exposes the local HTTP API.
- Model blobs: downloaded weights and metadata stored on persistent disk.
- A process supervisor: systemd starts Ollama after boot, restarts it after a failure, and records logs in the journal.
- An access layer: localhost-only access, an SSH tunnel, a private network, or an authenticated reverse proxy for clients outside the VPS.
Keeping these roles separate makes maintenance safer. You can replace the binary without deleting models, move the model directory to a larger volume without changing game clients, and change network policy without exposing the inference process directly to the internet.
Check the VPS before installing
Confirm these properties with your provider before downloading a model:
| Check | Why it matters | What to record |
|---|---|---|
| Architecture | The installer or archive must match the machine. | amd64 or ARM64 |
| System RAM and GPU memory | Weights, context, and concurrent requests consume memory. A model can run partly or entirely on CPU, but that changes speed and system load. | Total RAM, GPU type, and VRAM |
| Persistent disk | Model downloads are large and should survive reboots and binary updates. | Free space, mount point, and I/O performance |
| Operating system | The documented workflow targets Linux and systemd. | Distribution, release, and whether systemd is available |
| Network controls | Remote API access needs firewall rules, private networking, or a proxy. | Private-network support, inbound firewall policy, and egress limits |
| Geography and capacity | GPU availability and pricing vary by region and provider. | Region, recurring price, and whether the selected GPU is actually available |
Do not size a VPS from CPU core count alone. Compare GPU type and VRAM, CPU and system RAM, persistent disk capacity and I/O, architecture, network controls, the ability to run systemd (or an equivalent supervisor), and regional availability. Ollama’s official documentation does not establish one VPS size that is appropriate for all models.
Install Ollama on Linux
Use the official installer
On a supported Linux VPS, run:
curl -fsSL https://ollama.com/install.sh | shThe installer places the executable at /usr/bin/ollama on the standard system installation. Treat the command as a privileged installation step: inspect your shell, VPS image, and change-control policy before piping a remote script into a shell. If your environment does not allow that method, download the architecture-specific Linux archive and extract the binary manually.
Add GPU support only when you need it
GPU acceleration is optional. The Linux installation documentation provides separate paths for NVIDIA CUDA and AMD ROCm. Choose the path matching the GPU and driver stack supplied by your VPS provider, then restart the Ollama service after installing or changing drivers. A CPU-only deployment is valid, but a model that fits in GPU memory can avoid much of the CPU load and usually gives a better interactive experience.
Verify the binary
Check that the command resolves before creating the service:
command -v ollama
ollama --versionIf command -v returns nothing, the binary is not on the service user’s PATH or the installation did not complete. Fix the installation first; do not create a service that points at a nonexistent executable.
Run Ollama as a dedicated systemd service
Running the daemon from an interactive SSH session makes it vulnerable to logout and reboot. Use a system user and a systemd unit instead.
Create the service account
Create a system group and user if the installer has not already created them:
sudo groupadd --system ollama
sudo useradd --system --gid ollama --create-home
--home-dir /usr/share/ollama --shell /usr/sbin/nologin ollamaIf either account already exists, keep the existing account rather than creating a second one. The account needs read and write access to the model directory and any destination volume you later configure.
Create the unit file
Open the unit:
sudo nano /etc/systemd/system/ollama.serviceUse a minimal unit that starts the server after networking is available:
[Unit]
Description=Ollama Service
After=network-online.target
[Service]
Type=simple
ExecStart=/usr/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.targetThe important security properties are User=ollama and Group=ollama: model downloads and the serving process do not run as root. Restart=always lets systemd recover from an unexpected exit.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Enable, start, and inspect it
- Reload unit definitions:
sudo systemctl daemon-reload. - Enable startup at boot:
sudo systemctl enable ollama. - Start the service now:
sudo systemctl start ollama. - Inspect its state:
sudo systemctl status ollama.
A successful status should show an active service and an ollama serve process. If it exits immediately, use journalctl -e -u ollama before changing settings. The journal normally reveals a bad executable path, permission error, missing library, unavailable GPU driver, or an invalid environment value.
Download, run, inspect, unload, and delete models
Ollama’s command-line workflow is deliberately small. Replace <model> with the exact model name and tag you intend to use.
| Task | Command | What to expect |
|---|---|---|
| Download a model | ollama pull <model> |
Downloads model layers into the configured model directory. |
| Start an interactive session | ollama run <model> |
Loads the model and opens an interactive prompt. |
| List installed models | ollama list |
Shows locally available models and their sizes or tags. |
| Inspect metadata | ollama show <model> |
Displays model metadata and configuration information. |
| See loaded models | ollama ps |
Shows models currently resident in memory and their processor split. |
| Unload a model | ollama stop <model> |
Releases the model from memory without deleting downloaded files. |
| Delete a model | ollama rm <model> |
Removes the local model; download it again if you need it later. |
For a first test, the Ollama quickstart uses gemma4:e2b. That download is about 7.2 GB and the example recommends 8 GB of available VRAM or unified memory. Treat those figures as requirements for that example, not as a promise that every model will fit. Larger context windows need additional memory.
Understand CPU and GPU placement
Run ollama ps while a model is loaded. It reports 100% GPU, 100% CPU, or a split such as 48%/52% CPU/GPU. A split means part of the model resides in system memory and part in GPU memory. If a model does not fit entirely on one GPU, Ollama may spread it across available GPUs; if it fits on one GPU, the FAQ says Ollama will load it there.
Placement is a capacity decision, not merely a performance toggle. Check the process split, system memory, GPU memory, and service log before increasing context length or concurrency. A model that technically loads can still leave too little memory for the operating system, game server, proxy, or other workloads on the VPS.
Move the model directory to a larger disk
The Linux default model directory is:
/usr/share/ollama/.ollama/modelsIf the root disk is small, attach and mount a persistent volume first. Choose a mount point that will be present before Ollama starts, such as /srv/ollama-models.
Copy existing files safely
- Stop Ollama so files are not changing during the copy:
sudo systemctl stop ollama. - Create the destination:
sudo mkdir -p /srv/ollama-models. - Copy the existing model tree, preserving ownership and permissions:
sudo rsync -aH --info=progress2 /usr/share/ollama/.ollama/models/ /srv/ollama-models/. - Give the service account access:
sudo chown -R ollama:ollama /srv/ollama-models.
Confirm that the volume is mounted at the intended path on every boot. A missing mount can make the service write to the root filesystem or fail to find models, depending on the mount and directory state.
Set OLLAMA_MODELS in a systemd drop-in
- Open the supported override editor:
sudo systemctl edit ollama.service. - Under a
[Service]header, add:
[Service]
Environment="OLLAMA_MODELS=/srv/ollama-models"- Save the drop-in, then reload and restart:
sudo systemctl daemon-reloadfollowed bysudo systemctl restart ollama. - Verify the service is active and run
ollama list. The models should appear without downloading them again.
Using a drop-in keeps local changes separate from the main unit file, so an installer update is less likely to overwrite your storage configuration. If the list is empty, stop the service and check the path, mount, ownership, and the effective unit environment before pulling anything.
Recommended Free Tools
Configure memory, residency, and request behavior
Ollama exposes service environment variables for common VPS constraints. Set them in the same systemd drop-in pattern, then run sudo systemctl daemon-reload and sudo systemctl restart ollama.
| Variable | Purpose | Documented default or behavior |
|---|---|---|
OLLAMA_HOST |
Bind address and port for the server. | Ollama binds 127.0.0.1 on port 11434 by default. |
OLLAMA_CONTEXT_LENGTH |
Default context length for requests. | 4096 tokens; a per-request num_ctx can override it. |
OLLAMA_KEEP_ALIVE |
How long a model remains resident after a request. | Use it to trade faster repeat requests against memory occupancy. |
OLLAMA_MAX_LOADED_MODELS |
Maximum number of simultaneously loaded models. | Three times the number of GPUs, or three for CPU inference. |
OLLAMA_NUM_PARALLEL |
Parallel requests handled per model. | Defaults to one. |
OLLAMA_MAX_QUEUE |
Requests waiting for capacity. | Defaults to 512. |
For example, a conservative drop-in might contain:
[Service]
Environment="OLLAMA_CONTEXT_LENGTH=4096"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_QUEUE=64"Do not raise parallelism simply because a game plugin can send many requests. Parallel processing increases memory use in proportion to context length. Start with one parallel request, observe ollama ps and journalctl -e -u ollama, and increase limits only when memory headroom is proven.
Call the local API
Local requests do not require an API key. With the service running on the VPS, test the chat endpoint from the VPS itself:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
curl http://localhost:11434/api/chat
-H 'Content-Type: application/json'
-d '{"model":"gemma4:e2b","messages":[{"role":"user","content":"Reply with one short line."}],"stream":false}'The endpoint is http://localhost:11434/api/chat. Replace the model name with one installed by ollama pull. A JSON response confirms that the daemon, model directory, and selected model are working together.
Expose Ollama without turning port 11434 into a public service
The default localhost bind is the safest starting point. A game server, development laptop, or administration shell can reach it through an SSH tunnel or a private network without changing the Ollama listener:
ssh -L 11434:127.0.0.1:11434 user@your-vpsWith that tunnel open, a client on your workstation can address its own http://127.0.0.1:11434, while the VPS service remains bound to loopback.
If remote clients must connect directly, set OLLAMA_HOST deliberately in the systemd drop-in. An address such as 0.0.0.0:11434 listens on all IPv4 interfaces, which is an infrastructure access-control decision rather than a convenience setting. Restrict inbound firewall rules to trusted sources, or place an authenticated and TLS-terminating reverse proxy or private-network gateway in front of Ollama. Do not assume that the absence of an API key on local requests provides authentication for an internet-facing listener.
- Keep port 11434 closed to the public internet whenever a proxy or tunnel can meet the use case.
- Require authentication at the proxy for users and game services that are not on a trusted private network.
- Use TLS at the externally reachable endpoint.
- Limit proxy routes to the API operations your client needs and apply request-size, timeout, and rate limits.
- After changing
OLLAMA_HOST, restart the service and verify the listening address with your operating system’s socket tools.
Update Ollama and keep changes reproducible
To update an installed Linux deployment, rerun the installer or download the newer architecture-specific archive. If you need a pinned release for a repeatable game-server image, set OLLAMA_VERSION in the installer environment; the documented example is:
OLLAMA_VERSION=0.5.7 curl -fsSL https://ollama.com/install.sh | shThat version string is an example of pinning, not a recommendation that it is the newest release. Record the version used by your image and test the service after updating:
- Back up or snapshot the VPS and its model volume.
- Update the binary or archive.
- Run
sudo systemctl restart ollama. - Check
sudo systemctl status ollama,ollama list, and a local API request. - Review
journalctl -e -u ollamafor driver, permission, or migration errors.
Model files are separate from the executable, so updating the binary should not require redownloading models. Keep the storage path and systemd drop-in under configuration management if you recreate VPS instances.
Troubleshoot the failures that matter most
The service will not start
Run sudo systemctl status ollama and journalctl -e -u ollama. Check that /usr/bin/ollama exists, the unit has the correct spelling, the ollama user can read the binary and model directory, and every environment value is valid. A service that was edited requires sudo systemctl daemon-reload before a restart.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →ollama list is empty after moving storage
Verify that OLLAMA_MODELS is in the service drop-in rather than only in your interactive shell. Confirm the volume is mounted, the copied files are under the exact destination, and ownership is ollama:ollama. Restart the service after correcting the path.
The model is too large or the process is killed
Check available RAM and VRAM, then inspect ollama ps for CPU/GPU placement and the journal for allocation errors. Stop unused models with ollama stop, reduce context length, keep OLLAMA_NUM_PARALLEL=1, and avoid loading several models simultaneously. If the model still does not fit, choose a smaller model or a VPS with more memory; queue settings cannot create additional capacity.
Requests are slow or queue up
Look at the loaded-model split, current memory pressure, context length, and the queue. A GPU split across CPU and GPU may indicate that the model does not fit in VRAM. Increasing parallelism can increase throughput only when memory and compute headroom exist; otherwise it creates more waiting and may trigger evictions or failures.
A remote client cannot connect
First test locally on the VPS. If localhost works, inspect OLLAMA_HOST, the service restart, the VPS firewall, provider security rules, proxy upstream address, and private-network routing. If the listener remains on 127.0.0.1, use an SSH tunnel or proxy on the VPS; a remote machine cannot reach loopback directly.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchQuick Recap
Operational checklist for a game-oriented VPS
- Record the VPS architecture, RAM, GPU model, VRAM, disk mount, region, and recurring cost.
- Install the matching Linux binary and optional NVIDIA CUDA or AMD ROCm components only when required.
- Run Ollama as the dedicated
ollamauser through systemd. - Keep model files on persistent storage and verify the mount before booting the service.
- Pull only the models your game tools need; use
ollama listandollama showto inventory them. - Start with the 4096-token context default and one parallel request, then measure before raising limits.
- Use
ollama psand the journal to confirm placement and diagnose memory pressure. - Leave the API on localhost unless remote access is intentional and protected by a tunnel, private network, or authenticated proxy.
- Snapshot the VPS and model volume before binary updates, and test a real API request afterward.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
