Local AI on Contabo VPS

The Contabo shape of local AI

Local AI on Contabo is mostly a story about RAM, disk, and patience—not about Contabo shipping a managed model catalog. You rent a Core or Performance VPS, place weights on NVMe or SSD, run an inference runtime you chose, and expose it only as far as your threat model allows. Contabo’s job is capacity and network; your job is the stack.

That division is liberating. You can run Ollama-style workflows, llama.cpp servers, vLLM-class serving when the CPU/GPU story matches, embedding services, and RAG pipelines that keep private documents off third-party APIs. It is also demanding: you own CUDA-less CPU performance expectations, driver truth on GPU VPS, and the disk math when a 40 GB weight file meets a 100 GB plan.

This page plans procurement and architecture so Contabo’s price board becomes usable for private inference. Editorial lab boundaries live on About.

Start with the job, not the model fashion

Write the job in one sentence: private coding assistant for three developers; nightly batch summarization; image captioning for an internal DAM; voice-to-text for meeting notes; embeddings for a 10k-document wiki. Jobs dictate concurrency, context length, and whether interactive latency matters.

Interactive chat wants headroom—RAM free beyond weights, moderate concurrent sessions, and a reverse proxy with auth. Batch jobs want queue depth, disk for inputs/outputs, and cron or n8n triggers. Mixing both on Cloud VPS 6 without cgroup limits is how SSH freezes during a pull.

Also write the data boundary: may weights leave the VPS? may prompts leave to an external API? Contabo is the host; your compliance story is still yours. EU Hub placement helps some teams; it does not finish a DPIA.

Teams often underestimate “idle” cost of local AI: the model resident in RAM while nobody chats still occupies the Contabo plan you sized for peaks. If usage is spiky, consider smaller always-on embedding services plus on-demand larger models, or an external API for rare heavy jobs while Contabo hosts the orchestrator. Contabo’s flat monthly VPS economics reward steady residency; they are less magical when you need burst GPU for two hours a week—unless you accept paying for the GPU VPS all month.

Another job-shaping question: do you need multimodal pipelines (image in, text out; video frames; audio)? Multimodal stacks multiply disk and CPU. Contabo can host them, but your Contabo plan must look more like a workstation and less like a $6 hobby VM. Be explicit on the whiteboard before you click Cloud VPS 4 out of habit.

RAM and CPU planning on Core VPS

Contabo Core plans advertise 8 GB to 96 GB RAM across Cloud VPS 4–18 (as listed on Contabo — re-check). CPU-side local models live or die by RAM: resident weights plus context/concurrency memory plus runtime, OS, and application margin. A 7–8B quantized model may fit a mid plan; larger weights need Contabo’s upper Core tiers or Performance/GPU paths.

Rules of thumb for planning (teach the method; measure on your box):

• Leave several GB for OS, SSH, proxy, and monitoring—never allocate “all RAM to the model” on paper.
• Concurrent sessions multiply KV-cache pressure; one user demo is not five parallel chats.
• Embeddings-only services are often lighter than chat models; do not buy 64 GB for a small embedding endpoint without cause.
• If CPU inference is “usable but slow” for your job, that can still be a win versus API bills—so long as you accept the pace.

Contabo positions Core for cost-efficient everyday workloads and Performance for sustained compute. Saturating every vCPU with inference all day is the moment to reread Contabo’s Performance page rather than cursing Core for being Core.

Watch Contabo’s vCPU counts as throughput hints, not as marketing poetry. More vCPUs help parallel tokenize/batch, yet memory bandwidth and quantization choice often dominate user-felt latency on CPU. When Contabo Performance VPS exists as an upgrade path, read Contabo’s own “Core vs Performance” framing: Performance is for workloads that push CPU and NVMe harder. Local AI frequently is that workload.

NUMA and noisy neighbors are the unglamorous shared-VPS tax. If your interactive latency varies wildly by hour, gather evidence (load averages, steal time if visible) before you assume the model is wrong. Sometimes the fix is Performance or GPU VPS; sometimes it is reducing concurrency.

Disk floors and weight storage

Model files are the silent budget killer. Use the AiXVPS storage method: choose assumed weight size M (GB) and reserve R (GB) for OS, containers, indexes, and room to download a second model without deleting the first. Disk floor ≈ M + R. Compare to Contabo’s included SSD/NVMe and any storage extension.

Examples are placeholders for arithmetic—not Contabo quotes and not model recommendations. Pulling weights also consumes inbound bandwidth (ingress) and time on your port (200 Mbit/s on VPS 4 is a long coffee for big files). Core VPS provides CPU-based compute without a GPU. Some Core tiers advertise SSD or NVMe options with different capacities—verify the selected storage type and capacity in checkout. Performance is a separate product family. Use Performance when Contabo’s Performance specs match your I/O needs.

Recompute with the cost calculator and the storage & egress walkthrough.

Egress, ports, and fair use

Contabo advertises unlimited traffic with fair use and the right to throttle exceptional patterns. Local AI usually cares about ingress during pulls and egress during API sharing. A private VPN-only model endpoint barely moves the needle; a public demo that streams video-derived features might.

Port speed is the practical limiter. Design pulls to be resumable. Avoid turning Contabo into a distribution CDN for weights to the internet. If you must serve many remote clients, put a cache or object storage in front of large artifacts and keep the VPS as compute.

CPU vs Contabo GPU VPS — honest split

Standard Contabo Cloud / Core VPS plans are CPU/RAM/storage products. They do not silently include a consumer GPU. If your job needs substantial VRAM, Contabo’s separate GPU VPS exists: The historical research recorded a dedicated NVIDIA RTX PRO 6000 class card (96 GB VRAM) paired with 18 vCPU / 96 GB RAM / ~900 GB NVMe, Ubuntu 24.04 CUDA image, regions Europe and US Central at launch notes, list pricing on the order of €999 / $1199 / £969 per month excluding VAT with term discounts on Contabo’s blog—re-check live.

GPU VPS limitations Contabo documents matter: fixed configuration, no casual upgrade/downgrade, Auto Backup add-on not available (use other backup paths), capacity limited. That is a high monthly cost SKU that needs a clear VRAM requirement—not an upsell checkbox on Cloud VPS 8.

Decision sketch:

• CPU Core/Performance — private assistants, modest models, embeddings, batch jobs that can wait.
• GPU VPS — when VRAM and dedicated GPU throughput are requirements you can fund monthly.
• External API + Contabo n8n — when Contabo is the orchestrator and another provider holds the giant model.

Field checklist mindset: CPU vs GPU checklist.

Runtime patterns that fit Contabo

At a high level—without turning this into a tutorial that ages in six weeks— Contabo-friendly patterns look like:

• Ollama or llama.cpp style servers on Core/Performance for approachable CPU/GPU-host tooling when hardware matches.
• Open WebUI or similar frontends behind Caddy with authentication.
• vLLM-class serving when you are on hardware Contabo documents as CUDA-ready (GPU VPS) and you accept the operational complexity.
• Separate embedding container to keep chat load spikes from killing retrieval.
• Object storage or second disk path for datasets; keep the root volume boring.

Pin versions. Record the model digest. Contabo snapshots help roll back OS mistakes; they do not replace model provenance notes.

Same-box with n8n or WordPress

Same-box Contabo is tempting: one invoice, one IP. It fails when a model pull fills the disk n8n needed for executions, or when WordPress PHP workers fight inference for RAM. Default recommendation: split when models exceed toy size. Keep n8n on a mid Core plan; keep models on a larger RAM or GPU box; let n8n call the model over a private URL.

If you must same-box, use Docker memory limits, separate compose projects, and disk quotas. Snapshot before every model experiment.

Security for private inference

1. No open Ollama port on 0.0.0.0 without auth.
2. mTLS or VPN for team access when possible.
3. Prompt/PII logging policy—disks get snapshotted.
4. Separate Contabo firewall rules per service.
5. Pause workloads before backup for consistency—see billing & backup.

Worked scenarios on Contabo

Scenario A — Private team assistant on Cloud VPS 8 (24 GB). EU region; verify Core SSD/NVMe option in checkout or choose Performance as its own family, Caddy + Open WebUI + one 7–14B-class quantized model, VPN-only access. n8n lives elsewhere or lightly on the same box with memory limits. Snapshot weekly; Auto Backup on. Success looks like stable private chat without public ports. Failure looks like five concurrent long-context chats starving SSH.

Scenario B — Nightly document batch on Cloud VPS 12 (48 GB). Cron or n8n triggers a summarization job over object files stored on disk or Object Storage. Daytime RAM mostly free; nighttime batch spikes CPU. Contabo’s fair-use policy is Contabo’s to enforce—do not assume overnight CPU is invisible; read Contabo’s current AUP/traffic notes and keep workloads explainable. Success is emails with summaries; failure is disk filled by unsorted PDFs.

Scenario C — Orchestrator-only Contabo + external frontier API. Cloud VPS 6 runs n8n, stores credentials, never hosts giant weights. Contabo cost stays low; AI quality comes from APIs you already pay for. This is still “AI on Contabo” in the operational sense—pipelines live there—even though inference is remote.

Scenario D — Contabo GPU VPS for heavy single-node work. You verified Contabo’s GPU VPS stock in EU or US Central, accepted the monthly rate, and need VRAM Contabo’s Core plans never had. You follow Contabo’s CUDA Ubuntu image, skip assuming Auto Backup exists for that SKU, and design Backup Space/Object Storage exports yourself. Success is dedicated GPU throughput; failure is treating GPU VPS like a flexible spot instance.

Each scenario should be priced with location fees and add-ons in the calculator. Contabo’s sticker for Core is not the whole story once Sydney or Tokyo enters the cart.

Installation sequence that ages well

Illustrative CPU-only Ollama recipe. Use a clean Ubuntu/Debian host with Docker Engine, curl, Python 3, Bash, and at least 8 GB total RAM. Complete the SSH and firewall baseline first. This is one small local smoke test, not a concurrency promise. Use the Docker data filesystem for the disk check; change /var/lib/docker if your daemon stores data elsewhere.

VPS preflight: the example requires 6 GiB currently available RAM, reserves 20 GiB disk for the host, and budgets 12 GiB for this download, image layers, and temporary work. These are deliberately conservative starting estimates; inspect inode availability too.

set -euo pipefail
DOCKER_DATA=/var/lib/docker
sudo test -d "$DOCKER_DATA"
free -h
sudo df -h "$DOCKER_DATA"
sudo df -i "$DOCKER_DATA"
docker system df
AVAILABLE_KIB=$(awk '/MemAvailable:/ {print $2}' /proc/meminfo)
FREE_KIB=$(df -Pk "$DOCKER_DATA" | awk 'NR==2 {print $4}')
RESERVE_KIB=$((20 * 1024 * 1024))
WORK_KIB=$((12 * 1024 * 1024))
test "$AVAILABLE_KIB" -ge $((6 * 1024 * 1024)) || { echo 'Insufficient available RAM' >&2; exit 1; }
test "$FREE_KIB" -ge $((RESERVE_KIB + WORK_KIB)) || { echo 'Insufficient disk reserve' >&2; exit 1; }

Select a supported Ollama release from its official release/registry pages and record the matching platform image digest. Set both variables below to reviewed values in your shell. Placeholders fail closed; do not substitute latest. A digest pins the image bytes but does not establish that its publisher or model license is trustworthy.

set -euo pipefail
export OLLAMA_VERSION='REPLACE_WITH_REVIEWED_VERSION'
export OLLAMA_DIGEST='REPLACE_WITH_64_HEX_DIGEST'
[[ "$OLLAMA_VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]] || exit 1
[[ "$OLLAMA_DIGEST" =~ ^[a-f0-9]{64}$ ]] || exit 1
IMAGE="ollama/ollama:$OLLAMA_VERSION@sha256:$OLLAMA_DIGEST"
docker pull "$IMAGE"
# Use an unused container name and named volume on the checked filesystem.
if docker container inspect contabo-ollama >/dev/null 2>&1; then
  echo 'Existing container: inspect and back up before replacing it' >&2; exit 1
fi
docker volume create contabo_ollama_models >/dev/null
docker run -d --name contabo-ollama   --restart=on-failure:3 --memory=4g --memory-swap=4g --cpus=2 --pids-limit=256   --log-opt max-size=10m --log-opt max-file=3   -p 127.0.0.1:11434:11434   -e OLLAMA_HOST=0.0.0.0:11434 -e OLLAMA_NUM_PARALLEL=1   -e OLLAMA_MAX_LOADED_MODELS=1 -e OLLAMA_MAX_QUEUE=4   -e OLLAMA_CONTEXT_LENGTH=2048   -v contabo_ollama_models:/root/.ollama "$IMAGE"

The service listens on all interfaces inside its container so Docker forwarding works, but the host publishes only loopback. Host localhost and container localhost are different. Another container must use a deliberately shared private network and service name, or a tunnel reachable from its network; http://127.0.0.1:11434 inside n8n does not reach this host mapping. Leave the inference port blocked in the panel.

After reviewing the model's community license and acceptable-use terms, pull one small model. llama3.2:1b is an illustrative library tag, not an immutable version or quality recommendation. Record its full digest from the tags response, source, quantization, license revision, and pull date in your manifest before promoting it.

set -euo pipefail
READY=0
for ATTEMPT in {1..30}; do
  if curl -fsS --max-time 2 http://127.0.0.1:11434/api/tags >/dev/null; then
    READY=1; break
  fi
  sleep 2
done
test "$READY" -eq 1 || { docker stop contabo-ollama; exit 1; }
docker exec contabo-ollama ollama pull llama3.2:1b
curl -fsS --max-time 10 http://127.0.0.1:11434/api/tags
# Harmless prompt only: response files may contain sensitive data in real use.
umask 077
SMOKE=$(mktemp)
trap 'rm -f -- "$SMOKE"' EXIT
curl --fail --silent --show-error --max-time 180   http://127.0.0.1:11434/api/generate   -H 'Content-Type: application/json'   -d '{"model":"llama3.2:1b","prompt":"Reply with a short greeting.","stream":false,"keep_alive":0,"options":{"num_ctx":2048,"num_predict":32}}'   -o "$SMOKE"
python3 - "$SMOKE" <<'PY'
import json, sys
with open(sys.argv[1]) as f:
    result = json.load(f)
assert result.get('done') is True and result.get('response', '').strip()
print('Smoke response structure passed; inspect quality separately.')
PY
docker stats --no-stream contabo-ollama

If the pull or smoke request fails, stop the container, inspect disk/RAM and the error privately, and keep the endpoint closed to callers. An HTTP timeout may leave inference running; stop explicitly before retrying under memory pressure. Do not run a second model to diagnose the first failure. For upgrades, pause callers, stop the old runtime, preserve its volume and manifest, test a pinned replacement, then reopen callers. A volume containing changed model tags may need its own restore even if the old image is available.

Resumable files and provenance

For a separate GGUF download, use an immutable publisher URL and a SHA-256 value obtained through a trusted release manifest. This optional Bash sketch needs curl and sha256sum. The destination directory must be private to the operator; rerun the same URL/checksum to resume. Never execute a downloaded model file or pipe a remote installer to a shell.

set -euo pipefail
: "${MODEL_URL:?Set a reviewed immutable HTTPS URL}"
: "${MODEL_SHA256:?Set the expected publisher SHA256}"
[[ "$MODEL_URL" == https://* ]] || exit 1
[[ "$MODEL_SHA256" =~ ^[a-f0-9]{64}$ ]] || exit 1
umask 077
mkdir -p "$HOME/model-download"
cd "$HOME/model-download"
test ! -e model.gguf || exit 1
curl --fail --location --proto '=https' --proto-redir '=https'   --retry 3 --connect-timeout 20 --max-time 3600 --continue-at -   --output model.gguf.partial "$MODEL_URL"
printf '%s  %s\n' "$MODEL_SHA256" model.gguf.partial | sha256sum --check -
mv -- model.gguf.partial model.gguf

A failed checksum keeps the partial file unpromoted. Investigate the URL and expected digest, then quarantine that exact partial file before a clean retry. A nonempty file proves nothing about integrity. Model redistribution and commercial use depend on its license; private hosting does not remove those obligations.

OOM, pressure, and stop cues

Read these locally; application logs can contain prompts or internal addresses. The OOM flag can clear after a later successful run, so correlate kernel timestamps, restart counts, and memory statistics.

docker inspect --format 'OOM={{.State.OOMKilled}} exit={{.State.ExitCode}} restarts={{.RestartCount}}' contabo-ollama
docker stats --no-stream contabo-ollama
free -h
vmstat 1 5
sudo journalctl -k --since '-30 minutes' --no-pager | grep -Ei 'oom|out of memory|killed process' || true
# Stop new callers first, then stop inference if OOM/pressure persists:
docker stop --time 30 contabo-ollama

Stop or reduce context/concurrency when OOM events repeat, swap churn persists, SSH stalls, or disk reserve is consumed. Swap is not a replacement for RAM and cannot supply VRAM. Increase the container limit only after confirming host headroom. If measured resident memory exceeds the host budget, use order-new → migrate/verify → cancel-old; sustained CPU demand and a true GPU requirement are separate procurement decisions.

Capacity planning worksheet

Copy this into a note before Contabo checkout: (1) interactive vs batch; (2) max concurrent sessions; (3) context length class; (4) weight size M GB; (5) disk reserve R GB; (6) region; (7) storage type Contabo shows in cart; (8) Auto Backup required?; (9) same-box n8n yes/no. If any cell is blank, Contabo’s cheapest plan is a guess, not a decision.

Revisit the worksheet after the first week of real traffic. For capacity changes, order a new VPS, migrate and verify the model endpoint, then cancel the old service only after callers have switched successfully.

Where to go next

Connect AI automation Setup guide Local AI hub Cost calculator

Sources and updates

• Contabo docs — VPS specifications (Core storage options and Performance family—verify live)
• Contabo docs — GPU VPS (SKU, regions, limitations—verify live)
• Contabo VPS pricing (verify live)
• Ollama Docker, memory/context and parallelism, generate API, and illustrative model and license.
• Ollama releases; official image tags/digests.
• AiXVPS Local AI hub and storage & egress pages

Last editorial pass: 2026-11-05 (America/Los_Angeles, PST).