Running Two Ollama Pro Subscriptions on the Same Machine with Docker

Table des matières

Introduction
Why Twice the Same Thing?
The Heart of the Problem: The Device Key
Setup — Step by Step
The /v1/models API Trap
Result: Two Sessions, Two Accounts, Zero Conflict
Lessons Learned
To Go Further

reading time: 14 minutes

Two Pro subscriptions, one machine, one credit card, and zero network conflicts. How Docker allowed me to double my cloud inference capacity without buying a second PC.

Introduction

I have been using Ollama Pro for several months to power my OpenCode sessions with cloud models. The thing is, even with a Pro subscription, you quickly hit rate limiting when running several agents in parallel. The obvious solution: a second subscription.

But here is the drama.

Ollama identifies each machine by a unique SSH key — its famous Device Key. Two instances on the same OS would share the same identity, and it is impossible to link two Pro accounts to the same device. And as you might guess, I wasn’t going to buy a second laptop just for that.

The solution: cheat. Make Ollama believe it is running on two different machines, even though they share the same CPU, the same RAM, and the same network connection. Docker will provide us with a perfect isolation bubble.

Why Twice the Same Thing?

Before you call me a lunatic, let me explain the use case.

With a single Pro subscription, I can run a model like`deepseek-v4-pro:cloud`in an OpenCode session. The problem arises when I want two simultaneous sessions. Rate limiting quotas mean the second session lags or is simply rejected.

With two independent Pro subscriptions:

OpenCode Session 1 → Pro Account A (localhost:11434)
OpenCode Session 2 → Pro Account B (localhost:11435)

Each session has its own quota, its own context, and does not interfere with the other. It is human multi-processing.

Two Pro subscriptions = two different emails. The same credit card works — the Ollama payment system does not block multiple subscriptions from the same payment method. I’ve checked.

The Heart of the Problem: The Device Key

When you install Ollama, a pair of ed25519 SSH keys is generated in the identity directory:

$ cat /usr/share/ollama/.ollama/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...

This key is uploaded to Ollama’s servers during the`ollama signin`. This is what says "this machine belongs to such-and-such Pro account." If your two instances share the same`id_ed25519`file, they share the same identity. Game over.

The workaround: give our second instance its own identity directory, isolated in a Docker volume.

Setup — Step by Step

Prerequisites

A functional native Ollama installation (official script`curl | sh`)
Docker installed and functional
Portainer or docker-compose for deployment
Two Ollama accounts with two distinct emails

I used version`0.20.2`— the one provided by the official script and the corresponding Docker image.

Step 1: Create the Volume

A simple directory on the host will serve as a persistent volume for instance B’s identity:

mkdir -p ~/ollama-b-data

This folder will be mounted in the Docker container as`/root/.ollama`, where Ollama stores its identity keys, history, and models.

Step 2: Run the Docker Container

# docker-compose.yml
services:
  ollama-instance-b:
    image: ollama/ollama:0.20.2
    container_name: ollama-instance-b
    ports:
      - "11435:11434"
    volumes:
      - /home/cheroliv/ollama-b-data:/root/.ollama
    environment:
      - OLLAMA_HOST=0.0.0.0
    restart: always

What is happening here:

Host port11435is mapped to the container’s internal11434. Thus, the Docker instance listens on`:11435`without conflict with the native instance occupying`:11434`.
Volume`~/ollama-b-data`is mounted on`/root/.ollama`— this is where the SSH identity will be stored.
`OLLAMA_HOST=0.0.0.0`allows the container to accept external connections.

I deployed this stack via Portainer, but a simple`docker compose up -d`works just as well.

Step 3: Retrieve the Public Key

Since the container is blank on the first start, Ollama automatically generates a new SSH key pair in the volume. We retrieve the public key:

$ docker exec ollama-instance-b cat /root/.ollama/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDDQ+dvnfmuo49q5O8LOlvgZ39SKORFw47ry9k4H2jPc

I verify that this key is different from the one in the native instance:

# Instance native
$ cat /usr/share/ollama/.ollama/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGyF...(différente)

# Instance Docker
$ cat ~/ollama-b-data/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDDQ...(différente)

Two distinct keys, two separate identities. Done.

If your container restarts, it reuses the keys present in the volume. The identity is persistent. You will not lose the association with the Pro account.

Step 4: Register the Key on Ollama.com

Head to https://ollama.com/settings/keys → Add SSH Key. Paste the public key from the Docker instance and validate.

Then, link this identity to Pro account B:

$ docker exec -it ollama-instance-b ollama signin

The browser opens, we log in with the email of account B, and the token is associated with the container’s SSH key. We verify that everything is OK:

$ docker exec -it ollama-instance-b ollama signin
User: cherolivpro

Step 5: Test with a Small Free Model

Before spending the price of a Pro subscription, I want to be sure the pipe is working. I pull a small local free model to validate connectivity:

$ docker exec ollama-instance-b ollama pull qwen3:0.6b
pulling manifest
pulling 7f4030143c1c: 100% ▕██████████████████▏ 522 MB
success

$ curl -s http://localhost:11435/api/tags
{"models":[{"name":"qwen3:0.6b","model":"qwen3:0.6b",...}]}

Port`11435`responds, the model is served. Instance B is alive.

Once reassured, I move to pulling the actual Pro cloud model:

$ docker exec ollama-instance-b ollama pull deepseek-v4-pro:cloud
pulling manifest
pulling 31c3059e137e: 100% ▕██████████████████▏  344 B
success

344 bytes for a cloud model manifest — normal, the inference happens server-side, not locally. And here is the ultimate test:

$ curl -s http://localhost:11435/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-pro:cloud","messages":[{"role":"user","content":"Dis bonjour en une phrase courte."}]}'

{
  "id": "chatcmpl-480",
  "model": "deepseek-v4-pro",
  "choices": [{
    "message": { "content": "Bonjour !" },
    "finish_reason": "stop"
  }],
  "usage": { "total_tokens": 181 }
}

Hello to you too, instance B.

The `/v1/models` API Trap

I lost 20 minutes on a silly detail. When I configured the`ollama-b`provider in OpenCode, nothing appeared in the model selector. Nothing. Zip.

The reason? The`/v1/models`API of instance B returned`{"object":"list","data":null}`instead of`{"object":"list","data":[]}`when no model was pulled. The`null`value crashed the parsing on the OpenCode side, which failed to display the provider.

The solution: declare the models explicitly in the OpenCode configuration rather than relying on dynamic discovery.

~/.config/opencode/opencode.json

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": { "baseURL": "http://localhost:11434/v1" },
      "models": {
        "gemma4:e2b": { "name": "Gemma 4 E2B (local)" }
      }
    },
    "ollama-b": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama Instance B (Docker)",
      "options": { "baseURL": "http://localhost:11435/v1" },
      "models": {
        "qwen3:0.6b": { "name": "Qwen3 0.6B (B)" },
        "deepseek-v4-pro:cloud": { "name": "DeepSeek V4 Pro (B)" }
      }
    }
  }
}

With this explicit declaration, OpenCode immediately sees provider B and its models. One session restart, and the`/models`selector shows both instances side by side.

If you don’t see your custom provider in`/models`, don’t waste three hours restarting your terminal. Declare the models manually in`opencode.json`— it fixes the problem instantly.

Result: Two Sessions, Two Accounts, Zero Conflict

In the end, I can run two OpenCode sessions simultaneously:

Session 1 → /models → Ollama (local) → deepseek-v4-pro:cloud → Compte A
Session 2 → /models → Ollama Instance B (Docker) → deepseek-v4-pro:cloud → Compte B

Each session has its own quota, its own rate limit, and they don’t step on each other’s toes. Same machine, same credit card, two different emails.

And the best part? The Docker container is in`restart: always`. It survives system reboots without manual intervention.

Lessons Learned

Docker isolates everything, even identity— A simple volume bind mount is enough to give a container its own set of SSH keys, making it indistinguishable from a different physical machine in the eyes of Ollama.
Two emails, same CC— Ollama does not block multiple subscriptions from the same payment method. Only the email must be distinct.
Test for free before paying — Un ollama pull qwen3:0.6b (modèle libre, 522 Mo) permet de valider toute la chaîne réseau sans débourser un centime. Vous validez le plomberie d’abord, vous activez le Pro ensuite.
/v1/models with data: null breaks OpenCode— If you configure a custom provider with`"models": {}`, OpenCode attempts to discover models via the API. If the API responds`data: null`, the provider does not appear. Declare models explicitly.
Two accounts is human multi-processing— One Pro account = one active OpenCode session. Two accounts = two parallel sessions. For someone juggling several Gradle projects simultaneously, it’s a game changer.

To Go Further

Article published on 2026-05-08

HyperFrames-Gradle : Transforming AsciiDoc into MP4 Video
31 May 2026

Auditing my LLM Consumption: SQLite, OpenCode, Ollama Cloud, and Why My Pro Subscription Blows the Global Market Away
18 May 2026

The "Independent Plugin + Consumer Root" Architecture: Why My Gradle Builds Are Doubling
14 May 2026

The Knowledge Graph as a Recommendation Engine: How I Killed Chronological "Related Articles"
12 May 2026

Please enable JavaScript to view the comments powered by Disqus.

Introduction

Why Twice the Same Thing?

The Heart of the Problem: The Device Key

Setup — Step by Step

Prerequisites

Step 1: Create the Volume

Step 2: Run the Docker Container

Step 3: Retrieve the Public Key

Step 4: Register the Key on Ollama.com

Step 5: Test with a Small Free Model

The /v1/models API Trap

Result: Two Sessions, Two Accounts, Zero Conflict

Lessons Learned

To Go Further

Related articles

The `/v1/models` API Trap