Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteYou can run DeepSeek-R1 on your own Linux VPS without a DeepSeek API key by installing Ollama, pulling a DeepSeek-R1 model tag, and keeping Ollama’s API on the server’s loopback interface. The shortest working path is:
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
curl -fsSL https://ollama.com/install.sh | sh
ollama pull deepseek-r1:7b
ollama run deepseek-r1:7bThat example tag is only an example: available tags change, so select the current DeepSeek-R1 variant shown in Ollama’s model library. A production setup also needs persistent storage, a deliberate CPU/GPU choice, and a reverse proxy or private network if another machine must connect.
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What this deployment looks like
Ollama is the local model server. It downloads and runs a DeepSeek-R1 model on the VPS and exposes an HTTP API. Your application sends prompts to Ollama; prompts do not need to travel to DeepSeek’s hosted service when cloud features are disabled.
- VPS: 64-bit Linux, SSH access, sudo privileges, persistent disk and enough memory for the selected model, quantization and context length.
- Ollama: the runtime and REST server.
- Model files: stored on the VPS, normally under
/usr/share/ollama/.ollama/modelsfor a Linux installation. - Application access: local requests use
http://127.0.0.1:11434. Remote access should pass through a protected proxy, VPN or private network rather than exposing port 11434 directly.
There is no universal RAM, VRAM, throughput or monthly-price figure that applies to every DeepSeek variant. Quantization, context length, concurrent requests and the VPS hardware change the requirement substantially.
Local Ollama or DeepSeek’s hosted API?
These are separate connection paths. Choose local Ollama when you want model files and inference on infrastructure you control. Choose the hosted API when you prefer a managed endpoint and do not want to operate model-serving infrastructure.
| Decision factor | Ollama on your VPS | DeepSeek hosted API |
|---|---|---|
| Data path | Prompts go to your VPS and its local model process. With cloud features disabled, requests do not use Ollama’s cloud services. | Requests go to https://api.deepseek.com, the documented OpenAI-compatible endpoint. |
| Authentication | Direct local calls do not require a DeepSeek API key. You must still add authentication at any remote proxy you operate. | Requires an API key issued for the hosted service. |
| Cost model | You pay for the VPS, disk, bandwidth and any GPU allocation whether the model is busy or idle. No universal monthly amount is established because infrastructure varies. | Usage is billed according to the provider’s current hosted pricing and token accounting; check the current API documentation. |
| Maintenance | You handle Linux updates, Ollama updates, model downloads, backups, monitoring, firewall rules and incident response. | The provider operates the serving layer; you manage credentials, request handling and your application’s availability. |
| Version control | You choose when to pull a tag and can retain downloaded model files. Tags and variants in the Ollama library can change. | The provider controls the hosted model catalog and endpoint behavior documented for the account. |
| Scaling | Scaling means resizing or adding VPS instances, storage and (where needed) GPUs, then routing requests between them. | Capacity is requested through the hosted service, subject to its limits and policies. |
| Hardware | CPU execution is possible; supported NVIDIA and AMD paths can accelerate inference when the VPS, drivers and model fit. | No GPU is required on your servers. |
Provision the VPS
Use a supported 64-bit Linux installation
Choose a current 64-bit Linux distribution supported by your VPS provider. Confirm the architecture before installing:
uname -mAn output such as x86_64 indicates a conventional 64-bit x86 system. ARM64 VPSs can have different image and accelerator support, so verify compatibility with the Ollama release and your provider before committing.
Prepare access and storage
- Create a non-root administrative account, grant it sudo access and confirm SSH login with key authentication.
- Use persistent disk. Ephemeral boot storage can erase model files when the instance is rebuilt.
- Leave capacity for the operating system, Ollama, one or more model variants, logs and temporary downloads. Model storage depends on the chosen quantization and should be checked before pulling several variants.
- Measure available memory and disk before selecting a model:
free -h
df -hDo not treat a model’s parameter count as a complete sizing specification. Runtime overhead, the context window and simultaneous requests all consume additional memory.
Install Ollama on Linux
Use the official installer
- Connect to the VPS over SSH.
- Run the Linux installer:
curl -fsSL https://ollama.com/install.sh | shThe installer normally creates an Ollama service on systems using systemd. If your distribution or installation method does not create a service, start the server explicitly with ollama serve and keep that process supervised.
Verify the service
On a systemd installation, inspect the service:
sudo systemctl status ollamaIf it is stopped, start it and enable it at boot:
sudo systemctl enable --now ollamaWhen running Ollama manually, use a separate terminal or a process supervisor:
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteollama serveDo not start a second server on the same port while the systemd service is already running. The default REST listener is local at http://127.0.0.1:11434.
Docker as an alternative
Ollama publishes an official Docker image named ollama/ollama. A container deployment still needs persistent storage for the model directory and a deliberate network binding. Bind the host port to loopback unless a protected proxy or private network is in place. For NVIDIA acceleration in Docker on Linux, Ollama’s FAQ requires the NVIDIA Container Toolkit in addition to a working host driver. Containerized and native installations should not both try to own port 11434.
Pull and run a DeepSeek-R1 model
Select the current model tag
Open the current DeepSeek-R1 entry in Ollama’s model library and choose a tag that fits your available memory and desired quality. Tags such as deepseek-r1:7b identify a particular packaged variant, but the catalog and tag names can change. Record the exact tag you choose so deployment scripts and health checks use the same value.
Download the model
ollama pull deepseek-r1:7bThe first pull can take significant time and disk space. Keep the SSH session stable or use a terminal multiplexer. If the download is interrupted, run the same pull command again; Ollama can complete the model acquisition rather than requiring you to change the tag.
Start an interactive session
ollama run deepseek-r1:7bType a prompt at the interactive input to confirm that generation works. Exit with the client’s normal quit action, then leave the service running for API clients.
Test the REST API locally
Use Ollama’s documented chat endpoint from the VPS itself:
curl http://127.0.0.1:11434/api/chat
-H 'Content-Type: application/json'
-d '{"model":"deepseek-r1:7b","messages":[{"role":"user","content":"Say hello"}],"stream":false}'Replace deepseek-r1:7b with the tag you actually pulled. A successful response confirms that the listener, model name and local request path agree. If you omit "stream":false, the API can return streamed output; retaining it makes a one-request shell test easier to read.
Size CPU, memory and GPU resources
Why there is no single minimum
DeepSeek-R1 variants differ in parameter count and quantization. A longer context window reserves more memory, and concurrent requests multiply working memory. CPU-only execution can work on a sufficiently large VPS but generally trades lower infrastructure complexity for higher latency. Select the smallest variant that meets your quality and context needs, then validate it under your own workload rather than relying on a universal minimum.
NVIDIA acceleration
Ollama documents NVIDIA GPU support on Linux. Confirm that the VPS exposes a compatible GPU and that its driver is installed before expecting acceleration. In a Docker deployment, install and configure the NVIDIA Container Toolkit as required by Ollama’s FAQ, then expose the GPU to the container. A GPU with insufficient memory can still fail when the model or context is too large; a GPU-enabled instance is not automatically suitable for every tag.
AMD acceleration
Ollama documents AMD acceleration through ROCm on Linux. Check that the provider’s GPU, driver and ROCm stack are supported together. If the runtime cannot initialize the accelerator, fall back to CPU execution while you correct the driver or choose a compatible instance.
Control device selection
Ollama documents environment variables for selecting GPUs or forcing CPU execution. Apply those variables through the same mechanism that starts your server (a systemd environment or the container configuration), then restart Ollama and verify behavior with a representative request. Keep a record of the selected device so a service restart does not silently change performance.
Keep model files on persistent storage
On Linux, Ollama’s documented default model location is /usr/share/ollama/.ollama/models. Check the disk containing that path before pulling a large variant. To relocate models, create a persistent directory and set OLLAMA_MODELS for the Ollama service:
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →sudo install -d -o ollama -g ollama /srv/ollama-models
sudo systemctl edit ollamaAdd a service override:
[Service]
Environment="OLLAMA_MODELS=/srv/ollama-models"Then apply it:
sudo systemctl daemon-reload
sudo systemctl restart ollamaThe exact service account and group must match your installation. Ensure the ollama user can read and write the destination, and do not delete the original directory until a test pull and run succeed from the new location. For Docker, mount a persistent volume at the container’s model directory instead of relying on the container’s writable layer.
Secure network access
Leave the default listener on loopback
Ollama states: “Ollama binds 127.0.0.1 port 11434 by default.” That default prevents unsolicited connections from the public network. Keep it unchanged when your application runs on the same VPS.
Put a boundary in front for remote applications
If an application runs elsewhere, do not open port 11434 directly to the internet. Put Nginx, Caddy, a VPN or a private network in front of Ollama. The boundary should:
Recommended Free Tools
- Terminate TLS so credentials and prompts are encrypted in transit.
- Require authentication and authorize only the application identities that need inference.
- Forward requests to Ollama’s private address and port.
- Apply request-size, rate and timeout limits appropriate to your workload.
- Log access without recording sensitive prompt or response bodies unless your retention policy explicitly permits it.
Ollama documents reverse-proxy forwarding with Nginx and changing the bind address with OLLAMA_HOST. If you change the bind address, use a private interface or a proxy-only address whenever possible; a wildcard bind makes a firewall mistake immediately more dangerous.
Configure the service bind deliberately
For a systemd installation, set environment variables with a service override rather than exporting them only in your interactive shell:
sudo systemctl edit ollama[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"sudo systemctl daemon-reload
sudo systemctl restart ollamaIf the proxy is on another private interface, replace the loopback address with the intended private address and verify the firewall before restarting. Test both from the VPS and from an authorized client; an address change can make local test commands fail even while the proxy works.
Limit the VPS firewall
Allow SSH only from your administration source, plus the HTTPS or VPN port used by your protected entry point. Do not create a public allow rule for TCP 11434. Also restrict outbound access according to your privacy and update policy, and review firewall rules after changing the Ollama bind address.
Free tools Windows power users keep installed
One-click scans. No signup required.
Disable Ollama cloud features for local-only operation
If your requirement is that Ollama operate locally, set OLLAMA_NO_CLOUD=1. Ollama documents that this disables cloud models and web search. For a temporary shell test:
export OLLAMA_NO_CLOUD=1
ollama serveFor a systemd service, persist the setting in the service override:
sudo systemctl edit ollama[Service]
Environment="OLLAMA_NO_CLOUD=1"sudo systemctl daemon-reload
sudo systemctl restart ollamaOllama also supports disable_ollama_cloud in ~/.ollama/server.json. The tilde refers to the account running the server, which may be the dedicated ollama user rather than your SSH account. After changing the file, restart Ollama and confirm that the service inherited the setting. Local-only mode does not remove your responsibility to secure the VPS, protect backups and control who can call the local API.
Operate the deployment
Check health and logs
Use systemd status and logs when a service starts or stops unexpectedly:
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 →sudo systemctl status ollama
sudo journalctl -u ollama --since "1 hour ago"For a container, inspect the container status and logs through your container runtime. A health check should make a small request to the local chat endpoint using a model tag known to be installed; do not use a huge prompt for routine monitoring.
Update in a controlled window
Keep the Ollama runtime, Linux packages, GPU drivers and proxy software current, but change one layer at a time. Before an update, note the installed model tags, copy service overrides and verify that model files are backed up or reproducible. After updating, repeat a local API test and an application-level test with a non-sensitive prompt.
Manage disk and concurrency
Remove unused model variants only after confirming that no application or rollback plan needs them. Watch disk usage, memory pressure and swap activity. If multiple clients can call the endpoint concurrently, establish an application queue and an explicit timeout rather than allowing unbounded requests to exhaust the VPS.
Troubleshooting by symptom
ollama: command not found
The installer may not have completed, or the binary is outside the current user’s PATH. Re-run the official installer, reconnect your SSH session and inspect the systemd service. Do not download an unofficial binary to bypass a failed installation.
Connection refused on port 11434
- Check
sudo systemctl status ollamaand start the service if necessary. - If you used
ollama serve, confirm that process is still running. - Check whether another process already occupies port 11434.
- Confirm that your client is using the actual bind address after an
OLLAMA_HOSTchange.
“Model not found” or a failed pull
Copy the tag exactly from the current Ollama model library and run ollama pull before ollama run. Tags are mutable catalog entries; a tag that appeared in an older guide may no longer be available. Check disk capacity and network stability if the pull stops partway through.
Out-of-memory errors or an OOM-killed process
Stop other workloads, reduce concurrent requests, choose a smaller or more heavily quantized variant, or move to a VPS with more memory or GPU memory. Reduce the requested context length where your application permits. Adding swap can prevent an immediate process kill but usually does not make large-model inference fast enough for interactive use.
Inference is unexpectedly slow
Confirm whether the process is using CPU or the intended GPU. Check driver and ROCm/NVIDIA setup, and in Docker verify the required NVIDIA Container Toolkit configuration. A model that fits only by offloading heavily between system memory and GPU memory can be slower than a CPU run; test a smaller tag and the same prompt under identical conditions.
A remote application cannot connect
This is often correct behavior when Ollama is still bound to 127.0.0.1. Put the application behind the configured proxy or private network, verify proxy authentication and forwarding, and open only the proxy/VPN port in the firewall. Do not solve the symptom by publishing 11434 directly.
Model files disappear after a restart
Inspect the configured OLLAMA_MODELS value and verify that the directory is on persistent storage. In Docker, confirm that the volume is mounted at the model path and that the container was recreated with the same volume. Check ownership so the Ollama service account can write downloaded layers.
Quick Recap
Application integration checklist
- Pull and pin the exact model tag you intend to use.
- Keep Ollama on loopback when the application shares the VPS.
- For a separate application host, expose only a TLS-enabled, authenticated proxy or private-network address.
- Send requests to
/api/chatwith the exact model tag and a JSONmessagesarray. - Set client timeouts that accommodate generation, and handle streamed and non-streamed responses deliberately.
- Monitor memory, disk, GPU utilization, request duration and error rate without logging sensitive prompt content by default.
- Document the runtime version, model tag, quantization, context limit, bind address and cloud setting so the deployment can be rebuilt.
Final pre-production checklist
- 64-bit Linux VPS with SSH, sudo and persistent disk.
- Memory and accelerator capacity validated for the selected variant and context length.
- Ollama installed from the official Linux installer or run from the official
ollama/ollamaimage. - DeepSeek-R1 tag pulled and tested through the local REST endpoint.
- Port 11434 unavailable from the public internet.
- TLS and authentication enforced at any remote entry point.
- Firewall restricted to SSH and the proxy or VPN ports.
- Model directory backed up or reproducible, with correct ownership.
OLLAMA_NO_CLOUD=1ordisable_ollama_cloudconfigured when local-only operation is required.- Logs, resource alerts, update procedures and a rollback plan documented.
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.
