# Using Atlas with Ollama in 2026

> Ollama is an inference server rather than an MCP server, so Atlas points at its OpenAI-compatible endpoint on port 11434 and runs fully offline.

Atlas runs against Ollama by pointing at its OpenAI-compatible endpoint on port 11434. Ollama is an inference server rather than an MCP server, so Atlas runs fully offline while keeping every MCP server configured on the Atlas side. Run ollama serve, add a provider in atlas.json with baseURL http://localhost:11434/v1 and any placeholder apiKey, and pull a tool-capable model first, for example ollama pull qwen3-coder, because Atlas's agent loop depends on function calling.

## Ollama is an inference server, not an MCP server

Ollama is an inference server rather than an MCP server, so Atlas points at its OpenAI-compatible endpoint on port 11434 and runs fully offline while keeping every MCP server configured on the Atlas side. Ollama supplies tokens. Atlas supplies the agent loop and the tools.

The distinction decides where your configuration lives. Ollama is not an MCP client, so your MCP servers stay configured in Atlas, never in Ollama. People lose an afternoon looking for an Ollama setting that would attach a filesystem or a GitHub server to the model; there is no such setting, and there should not be. Ollama's job ends at the OpenAI-compatible API on port 11434. Everything about tools, plans, edits, and approvals happens in Atlas.

## Starting Ollama and pointing Atlas at port 11434

Run ollama serve, then point Atlas at the OpenAI-compatible endpoint at http://localhost:11434/v1. Port 11434 is Ollama's default, and the /v1 suffix is what makes the endpoint speak the OpenAI API shape that Atlas's provider configuration expects out of the box.

Start with ollama serve in one terminal and confirm the port is listening before you touch Atlas at all. A provider that cannot reach http://localhost:11434/v1 fails in a way that looks like a model problem and is actually a process problem. Once the server responds, the Atlas side is a short configuration edit rather than a plugin install: Atlas already speaks the OpenAI wire format, so an OpenAI-compatible Ollama endpoint needs no adapter in between.

## Configuring the Ollama provider in atlas.json

Add Ollama as a provider in atlas.json with baseURL http://localhost:11434/v1 and any placeholder apiKey, which Ollama requires but ignores. The placeholder key trips people up: the field cannot be empty, and its value is never checked, so any non-empty string works.

The apiKey field exists because the OpenAI client contract demands it, and Ollama accepts whatever you send. Put a literal placeholder there rather than plumbing a secret manager into a local server that does not authenticate. The meaningful field is baseURL, and http://localhost:11434/v1 is the value that matters. With those two set, Atlas treats Ollama exactly as it would treat any other provider, and every Atlas feature that does not require the network keeps working.

## Pull a tool-capable model, because the agent loop needs function calling

Pull a tool-capable model first, for example ollama pull qwen3-coder, because Atlas's agent loop depends on function calling. A model without tool support will answer your question in prose and never call a tool, which looks like Atlas being broken when the model is simply the wrong one.

This is the highest-value line on the page. Atlas does not merely chat: it reads files, runs commands, and edits code by emitting tool calls, and a model that cannot emit them cannot drive the loop. ollama pull qwen3-coder gets you a model that can. If you swap in another local model and Atlas suddenly stops touching your filesystem, check tool support before you check anything else, because a model that cannot call functions cannot be an agent.

## Running Atlas in a container against Ollama on the host

Set OLLAMA_HOST to 0.0.0.0:11434 when Atlas runs in a container and Ollama runs on the host. By default Ollama binds to localhost, which a container cannot reach, so the connection fails even though the server is running perfectly well on the host machine.

Binding to 0.0.0.0:11434 tells Ollama to accept connections from outside the loopback interface, which is what makes the containerized Atlas process able to reach it. Treat this as a deliberate exposure: the port is now reachable from your network, so apply whatever host firewall rules your environment expects. When Atlas and Ollama run on the same machine outside a container, leave OLLAMA_HOST alone and use http://localhost:11434/v1 as it is.

## The daily workflow: offline refactors on Ollama, plan steps elsewhere

Use the local Ollama model for offline refactors, then switch providers for the reasoning-heavy plan step. In 2026 that split is the practical way to run Atlas on Ollama: local tokens are free and private, and the hardest planning work is where a stronger model still earns its cost.

Mechanical work suits a local model well. Renames, extractions, boilerplate, and repetitive edits across many files run entirely on your machine through http://localhost:11434/v1, with no code leaving the laptop and no per-token bill. Architectural planning is different, and that is where switching to another provider pays. Because Atlas holds the MCP server configuration and the agent loop, swapping the inference provider changes nothing about your tools: the same servers stay attached either way.

## Setup

1. Run ollama serve, then point Atlas at the OpenAI-compatible endpoint at http://localhost:11434/v1
2. Add it as a provider in atlas.json with baseURL http://localhost:11434/v1 and any placeholder apiKey, which Ollama requires but ignores.
3. Pull a tool-capable model first, for example ollama pull qwen3-coder, because Atlas's agent loop depends on function calling.
4. Set OLLAMA_HOST to 0.0.0.0:11434 when Atlas runs in a container and Ollama runs on the host.
5. Keep your MCP servers configured in Atlas, since Ollama is not an MCP client and never will be.
6. Use the local model for offline refactors, then switch providers for the reasoning-heavy plan step.

## FAQ

### how do I use Atlas with Ollama

Run ollama serve, then point Atlas at the OpenAI-compatible endpoint at http://localhost:11434/v1 by adding a provider in atlas.json with that baseURL and any placeholder apiKey.

### does Ollama support MCP servers

No. Ollama is not an MCP client, so your MCP servers stay configured in Atlas, never in Ollama. Ollama is an inference server rather than an MCP server.

### why doesn't Atlas call any tools with my local Ollama model

Because the model probably lacks function calling. Pull a tool-capable model first, for example ollama pull qwen3-coder, since Atlas's agent loop depends on function calling.

### what port does Ollama use with Atlas

Port 11434. Atlas points at the OpenAI-compatible endpoint at http://localhost:11434/v1, which is where ollama serve listens by default.

### what apiKey do I use for Ollama in atlas.json

Any placeholder apiKey works, because Ollama requires the field but ignores its value. The field that matters is baseURL set to http://localhost:11434/v1.

### how do I reach Ollama from a container running Atlas

Set OLLAMA_HOST to 0.0.0.0:11434 when Atlas runs in a container and Ollama runs on the host, since Ollama binds to localhost by default and a container cannot reach that.

### can I run an AI coding agent completely offline with Ollama

Yes. Atlas points at Ollama's endpoint on port 11434 and runs fully offline. Use the local model for offline refactors, then switch providers for the reasoning-heavy plan step when you want more capability.

---

Canonical HTML: https://runatlas.sh/resources/integrations/ollama
Source of truth: aeo_pages row `/resources/integrations/ollama` (segment: Integrations) (this file is generated from it, never hand-edited).
Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.
