Coming from Ollama

This server serves the Ollama API natively, so an existing Ollama setup migrates by changing the host: the CLI, Open WebUI, LibreChat, scripts, and integrations keep working. This guide maps each Ollama habit to its equivalent here, states the divergences plainly, and covers the part Ollama never had: authentication, teams, and everything beyond chat.

1The switch is the host#

Point OLLAMA_HOST (or whatever host setting your client exposes) at this server's root, http://your-server:PORT, and the /api dialect answers as the client expects: /api/chat, /api/generate, /api/embed and /api/embeddings, /api/tags, /api/show, /api/ps, /api/version, /api/pull, /api/create, /api/copy, /api/delete, and blob uploads. Streaming is newline-delimited JSON and is the default, matching Ollama. Vision (base64 images), tool calling, structured output through the format field, and the think field on thinking-capable models all ride the same shapes.

On a loopback-only install with anonymous access enabled (the default posture), no credential is needed, which matches the daemon you are leaving. The moment other machines connect, keys become mandatory: section 5.

LM Studio users follow the same playbook through the OpenAI dialect instead: base URL http://your-server:PORT/v1 plus a key, per API Compatibility.

2The command map#

Each verb you use today, and what it becomes:

Downloads started over /api/pull join any in-flight download of the same model and continue server-side if the client disconnects; they are observable and cancellable from the admin panel.

3Your model library#

Pulling. /api/pull accepts this server's catalog ids (browse them in Models, or GET /api/tags) and hf.co/owner/repo[:quant] references, which import as custom models through the server's egress policy, with hub-declared digests verified while downloading:

curl http://your-server:PORT/api/pull -d '{"model": "gemma4:12b"}'
curl http://your-server:PORT/api/pull -d '{"model": "hf.co/owner/repo:Q4_K_M"}'

Importing what you already have. A GGUF file on disk imports from the Models section by local path or URL; the import probes the file first and refuses what cannot serve. Files Ollama itself downloaded sit in its content-addressed blob store under digest names rather than as named .gguf files, so re-pulling by name here is usually less work than excavating blobs. Before an import ships to a team, run the pre-import protocol (license check, sizing, sanity check) from The Right Model for Your Machine; what rides each model's license is Licensing and What You May Build.

Modelfiles. ollama create works: blobs push over /api/blobs, and /api/create builds a model from a catalog base (from), pushed files (files, a main GGUF plus an optional mmproj entry), with LoRA adapters, and quantize to requantize into a requested precision with streamed progress. SYSTEM, TEMPLATE, PARAMETER, and LICENSE lines are recorded as the new model's profile and reported by /api/show, but none of them alter serving: rendering follows the model's own chat template, the recorded system prompt is not injected, and generation settings come from each request. To pin behavior server-side, define an agent (a named bundle of prompt, skills, tools, and memory: The Agent Platform); per request, the system field works on every dialect. Created models serve beside the catalog on every listing, marked Unverified.

4Where the dialect diverges#

• /api/push answers 501, deliberately. This server is not a model registry. Publishing runs the other way: pull from hf.co references, import from disk, or build with create; a custom model's artifact path is available from the admin API for publishing with the hub's own tools.
• /api/generate rejects raw, suffix, template, and context with a clear error rather than half-honoring them; use /api/chat for multi-turn conversations.
• keep_alive is accepted, not obeyed as a timer. An empty message list preloads a model; keep_alive: 0 unloads it. Standing residency is decided by the server's memory-pressure policy, which is why /api/ps shows no expiry countdown.
• The truncate flag on /api/embed is accepted and ignored: over-long inputs are chunked and mean-pooled by the runtime instead of cut off.
• Model names are this server's ids. A name the server does not know answers 404, the honest signal to finish the mapping (Choosing and Operating Models).

5Authentication when you leave loopback#

Ollama has no authentication; this server does, and the posture decides when it applies (Going Live):

• Loopback only (default): keyless calls are accepted while the anonymous toggle is on, so a personal setup migrates with zero credential ceremony.
• Network: every API call must present a key, on the Ollama dialect exactly as on the others: Authorization: Bearer lmk_.... Mint keys in Access, one per consuming system (Keys and Authentication).

Clients that can attach a header (Open WebUI, SDKs, scripts, HTTP nodes) work over the network unchanged. The official ollama CLI has no setting for attaching a key to a custom host as of early 2026, so treat it as a loopback tool: run it on the server itself, or use the admin panel and native API for remote model management.

6Open WebUI in five minutes#

The most common front-end migrates in one connection edit:

1. Add the connection in Open WebUI's connection settings, either as an Ollama connection at http://your-server:PORT or as an OpenAI connection at http://your-server:PORT/v1. Both dialects are served; either works.
2. Paste a key minted in Access; recent Open WebUI versions send it as a Bearer header on both connection types. On a loopback-anonymous install the field can stay empty.
3. Models appear automatically from the server's listing (/api/tags or GET /v1/models).
4. Open WebUI in Docker, server on the host: the container cannot reach the host's localhost; use host.docker.internal as the host. The full container-to-host pattern, Linux flag included, is in Automating with n8n, section 3.
5. For a team, mint one key per user instead of sharing one: the request trail in the admin console then attributes every call.

Open WebUI's embedding settings can point at the same server through either dialect (Embeddings and Reranking).

7What the switch adds#

The Ollama dialect is the compatibility door; the rest of the server is why the move pays:

• Real access control: least-privilege keys with scopes, expiry, and grants (Keys and Authentication), a safe network posture (Going Live), and SSO where you run an identity provider (Single Sign-On).
• Teams: per-key isolation everywhere, and tenancy for shared deployments (One Server, Many Teams).
• Three dialects side by side: OpenAI and Anthropic surfaces next to Ollama's, so tools that never spoke Ollama connect too (API Compatibility, Local Coding Assistants).
• Beyond chat: document conversion and OCR (Document Processing), validated field extraction (Structured Extraction), a full search engine with cited answers (The Search Engine), and agents (The Agent Platform).
• An operator surface: the admin console shows every request, every model's residency, and every download; capacity is a policy you set, not a surprise (Inference Capacity, Observability).

8Stated plainly#

• The Ollama API is served natively: for most setups, migration is one host change.
• /api/push is 501 by design; models are pulled, imported, or created, never pushed out.
• Modelfile creation works and the profile is recorded, but nothing in it alters serving: pin behavior with an agent or the per-request system field.
• Loopback keeps the keyless habit; the network posture requires a Bearer key on every call.
• The dialect is the door, not the product: keys, teams, documents, search, and agents are what you switched for.