A sleeping laptop is a poor server. Moving Ollama to a cloud VM solves that availability problem, but it does not turn shared CPU into a fast inference accelerator. On October 26, 2026, DigitalOcean listed a regular Basic Droplet[1] with 2 shared vCPUs and 4 GiB RAM at $24 per month; the 4-vCPU, 8-GiB plan was $48. Those are useful prices for planning a small, private endpoint, provided you treat the VM as a service to operate and the model as a workload to measure.
Buy memory for the model, then measure the CPU
The tempting arithmetic is to compare a model's download with the Droplet's RAM and declare a fit. That misses the operating system, Ollama itself, temporary buffers, and the model's key-value cache. Ollama says required RAM scales with parallel requests and context length[2]. Its llama3.1:8b Q4 download alone is 4.9 GB, already larger than the 4-GiB VM's entire memory allocation. A 4-GiB plan is a place to experiment with a smaller model and a short context; an 8B assistant needs more room. Even the 8-GiB plan needs a real memory check before you call it sufficient.
DigitalOcean describes Basic Droplets[3] as shared-CPU machines for bursty work that tolerates variable CPU access. Inference can occupy the CPU continuously while it produces an answer. More RAM may let the process start, but it cannot promise an acceptable token rate. If steady latency matters more than a low monthly cap, compare the dedicated-CPU plans too. The honest comparison records the exact Droplet plan, model tag and digest, quantization, context length, Ollama version, and prompt workload. A borrowed tokens-per-second number omits too many of those variables to answer your question.
Start with a model small enough to test the whole setup. Ollama lists llama3.2:3b as a 2.0 GB download; that makes it a reasonable first probe on the 8-GiB plan, not a guarantee of runtime fit or useful output. Pull and run the named tag:
ollama pull llama3.2:3b
ollama run llama3.2:3b
The task is the other half of the sizing decision. Test the model against prompts whose answers you can judge, and measure latency separately. If it cannot do the job, paying for a larger VM may shorten the wait but will not improve the model's underlying capability. Save the tag's digest from /api/tags alongside results so a later model update does not masquerade as a hardware change.
Make a private service before you make a convenient one
Choose a current long-term-support Linux image and add an SSH key when you create the Droplet. DigitalOcean Monitoring is available at no additional cost; automated backups add a charge. Decide whether you need those services while estimating the bill. Apply operating-system updates before installing Ollama. On Ubuntu, this is a starting host configuration, assuming SSH uses port 22:
sudo apt update
sudo apt upgrade
sudo apt install ufw curl less zstd
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable
Confirm the actual SSH port and keep a working session open when enabling the firewall; a rule for the wrong port can cut off remote access. A DigitalOcean Cloud Firewall[4] is a separate network control, so configure its inbound SSH source and outbound access for updates and model downloads deliberately. Its rules do not appear in UFW. A firewall at either layer can interrupt the service, which is why the two rule sets belong in your runbook rather than in someone's memory.
Use the install command on Ollama’s official Linux page[5] at setup time. Downloading the script first lets you inspect the exact file you are about to run:
curl -fsSL https://ollama.com/install.sh -o ollama-install.sh
less ollama-install.sh
sh ollama-install.sh
Then check the installed version and the service status with ollama --version and systemctl status ollama. Record that version with any benchmark. Ollama's local API binds to 127.0.0.1:11434 by default and does not require authentication[6]. That combination is sensible on the VM itself and dangerous if you casually change the bind address to 0.0.0.0 and expose port 11434 to the internet: anyone who reaches it could send model requests.
For one user, an SSH tunnel is enough. From your computer, run:
ssh -N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:11434:127.0.0.1:11434 your-user@your-server
Keep the tunnel open while using http://127.0.0.1:11434 from local tools. If that port is already in use, choose a different local port in the tunnel and use the same port in your tool’s URL. Check the connection with curl http://127.0.0.1:11434/api/tags. The SSH connection carries the local request to the VM without publishing Ollama's API port. If several trusted devices need access, a private overlay network may be easier to operate. Bind only on the intended private interface and put authentication in front of the API whenever that network includes a device or person you cannot fully trust. Transport encryption protects the connection; it does not decide who may use the model.
Prove the service works for your workload
The useful benchmark is the request your application will actually send, not a claimed rate from somebody else's host. Ollama’s generate API[7] reports model load time, prompt evaluation time, and output evaluation time separately. Send a non-streaming request and retain the response:
curl -s http://127.0.0.1:11434/api/generate \
-d '{
"model": "llama3.2:3b",
"prompt": "Summarize the following deployment note in five bullets: ...",
"stream": false,
"options": {"num_ctx": 2048, "temperature": 0}
}' > result.json
Run it once after the model has unloaded and again while it is warm. Repeat with your longest likely prompt and, if several clients will use the endpoint, with concurrent requests. Watch memory and failures as closely as token rate. Ollama's keep_alive request setting or OLLAMA_KEEP_ALIVE environment setting controls how long a model stays loaded. Keeping it resident can reduce a later load delay, but it also occupies memory that a small VM cannot spare for another job. A good result for a single warm request is therefore only one piece of the decision.
Count the operating bill
The recurring charge buys an awake machine, not freedom from server work. Keep the OS and Ollama updated, restrict SSH access, monitor disk and memory, set a provider spend alert[8], review both firewalls after changes, and test a backup restore before trusting the backup. The same maintenance discipline applies to other private remote services[9]. When the experiment ends, destroy the Droplet and any other billable resources you no longer need.
DigitalOcean's regular Basic price snapshot, checked October 26, 2026, was:
| Configuration | Listed monthly price |
|---|---|
| 2 shared vCPUs / 4 GiB RAM | $24 |
| 4 shared vCPUs / 8 GiB RAM | $48 |
Check live Droplet pricing[1] before purchasing. Four GiB and shared CPU may make the model you actually need a poor fit. If your measured task works on a small model, the VM can be a useful always-on endpoint. If it does not, choose a different model or plan rather than assuming the price table promises a token rate.
