Ollama is a managed instance for running large language models (LLMs) inside your own VPC. It provisions a VM from explicit compute and disk offers, installs Ollama, pulls the models you list — from the ollama.ai library or directly from Hugging Face — and serves them over an OpenAI-compatible REST API on port 11434 — plus a browser chat UI (Open WebUI) on port 3000.

Key concepts

• Models — the LLMs pulled onto the instance at startup (spec.models, e.g. llama3, mistral, gemma, or a Hugging Face GGUF reference like hf.co/bartowski/Llama-3.2-1B-Instruct-GGUF:Q4_K_M — the :quant suffix is optional and defaults to Q4_K_M; verify the exact quant tag exists in the target repo before provisioning, since an unresolvable reference is silently excluded from size validation rather than blocking creation)

• Compute & storage — offer IDs size the VM (spec.vmOfferId) and its data volume (spec.volumeOfferId, spec.volumeSizeGiB); large models need generous RAM and disk — creation is rejected up front with an estimated GiB figure if the requested volume is too small for the requested models

• Network — the instance runs in spec.vpcSubnetId; attach a spec.floatingIpId to reach it from outside the VPC

• API endpoint — once running, status.host serves the Ollama REST API (OpenAI-compatible /v1/chat/completions) on port 11434, gated behind HTTP Basic Auth using spec.rootPassword

• Web UI — status.host also serves Open WebUI on port 3000; a first admin account is created automatically (username root, email root@kvindo.local, password spec.rootPassword — the same value used for the API's Basic Auth). Open WebUI has its own sign-in, so port 3000 itself is not additionally gated by Basic Auth

Resource requirements

Concurrency. Each model runs in its own Docker container, capped to its measured resident memory plus a fixed 2 GiB KV-cache margin (applied per model, not once total). How many requests one model can serve concurrently (OLLAMA_NUM_PARALLEL) is derived automatically as max(1, floor(VM RAM / (model's measured RAM + 2 GiB))) — a small model using ~10% of the VM's RAM might get 10 concurrent slots, one using just over half gets exactly 1 (never 0, never rounded up). Not directly configurable; it scales with the VM offer and models you choose. Requests beyond that number aren't rejected — they queue for the next available slot, at the cost of latency.

RAM. Creation is validated against spec.vmOfferId's RAM before any VM is provisioned, and checked before disk (see below). Since each model is isolated, only the single largest requested model has to fit — not the sum of all of them — plus a fixed 2 GiB margin. If it doesn't fit, creation is rejected immediately: Model requires ~X GiB RAM, but the selected VM offer only has N GiB. This check has no separate margin for the OS, Docker, or Open WebUI's own RAM use — if you plan to run multiple models concurrently, size RAM for their combined footprint, not just the largest one. An offer's exact RAM is shown in the offer picker on the console's create form (e.g. g3-2c4-100 = 2 vCPU / 4 GiB RAM); there's no separate list endpoint in the SDK/CLI today.

Disk. Checked after RAM (if RAM fails, disk isn't evaluated) against spec.volumeSizeGiB. Unlike RAM, disk usage is additive across every requested model: the volume must cover a fixed ~16 GiB baseline (OS, the Ollama and Open WebUI container images, Open WebUI's own data volume, and a safety margin) plus each model's full download size plus an estimated swap-file allowance (models' estimated combined memory need, above the VM's usable RAM, is assumed to spill into swap — this estimate is based on measurements of models under 2 GiB and is deliberately conservative, not guaranteed-precise for much larger ones). If the volume is too small, creation is rejected with a full breakdown: Deploying N model(s) requires ~X GiB disk (... GiB base OS + ... GiB Ollama image + ... GiB Open WebUI image + ... GiB model blobs + ~... GiB estimated swap), but the selected volume is only Y GiB. This check depends on looking up each model's real download size from its registry (ollama.ai or Hugging Face) — if that lookup fails for any model (registry unreachable, ambiguous or missing quant match), that model is simply not counted rather than blocking creation, so passing this check is not an absolute guarantee for every model.

Examples

An instance in an existing subnet, pulling two models. Ollama is not in the Terraform provider, so only the SDK and CLI are shown.

Python SDK

kc CLI

Related pages

Resource docs

• VPC Subnet resource docs
• Floating IP resource docs
• Security Group resource docs

Reference

• kc-sdk-python on PyPI