Twee Ollama Pro-abonnementen combineren op dezelfde machine met Docker
Gepubliceerd op 08 May 2026
Twee Pro-abonnementen, één machine, één bankkaart en nul netwerkconflict. Hoe Docker mij in staat stelde om mijn cloud inferentiecapaciteit te verdubbelen zonder een tweede pc te kopen.
Introductie
Ik gebruik Ollama Pro al enkele maanden om mijn OpenCode-sessies te voorzien van cloudmodellen. Het truc is dat je, zelfs met een Pro-abonnement, snel wordt beperkt door rate limiting wanneer je meerdere agents parallel start. De voor de hand liggende oplossing: een tweede abonnement.
Maar daar, dat is het drama.
Ollama identificeert elke machine met een unieke SSH-sleutel — zijn beroemde Device Key. Twee instanties op hetzelfde OS zouden dezelfde identiteit delen, en het is onmogelijk om twee Pro-accounts aan hetzelfde apparaat te koppelen. En zoals je verwacht, ik zou geen tweede laptop kopen alleen daarvoor.
De oplossing: vals spelen. Ollama laten geloven dat het op twee verschillende machines draait, terwijl ze dezelfde CPU, dezelfde RAM en dezelfde netwerkverbinding delen. Docker zal ons een perfecte isolatiebubbel bieden.
@startuml
!theme plain
skinparam BoxPadding 10
skinparam DefaultFontSize 12
left to right direction
node "Fysieke Machine" {
frame "Ollama Instantie A (Native)" as Native {
database "Identiteit\n/usr/share/ollama/.ollama/id_ed25519" as KeyA
portin "API\n:11434" as PortA
}
frame "Ollama Instantie B (Docker)" as Docker {
database "Identiteit\n~/ollama-b-data/id_ed25519" as KeyB
portin "API\n:11435" as PortB
}
}
cloud "Ollama Cloud" {
actor "Pro Account A\n(email 1)" as AccountA
actor "Pro Account B\n(email 2)" as AccountB
}
KeyA --> AccountA : "SSH-sleutel A"
KeyB --> AccountB : "SSH-sleutel B"
PortA --> AccountA : "Aanvragen A"
PortB --> AccountB : "Aanvragen B"
note bottom of Docker
Geïsoleerde container: afzonderlijke SSH-identiteit,
afzonderlijke netwerkpoort, persistent volume
end note
@enduml
Waarom twee keer hetzelfde ?
Voordat je me gek noemt, laat me je het gebruikscasus uitleggen.
Met één Pro-abonnement kan ik een model lanceren zoals`deepseek-v4-pro:cloud`in een OpenCode-sessie. Het probleem doet zich voor wanneer ik twee sessies simultaan wil. De rate limiting-quota zorgen ervoor dat de tweede sessie vertraagt of volledig wordt afgewezen.
Met twee onafhankelijke Pro-abonnementen:
-
Sessie OpenCode 1 → Pro-account A`localhost:11434`)
-
Sessie OpenCode 2 → Pro-account B`localhost:11435`)
Elke sessie heeft zijn eigen quotum, eigen context, en stoort de ander niet. Dit is menselijke multi-processing.
|
Twee Pro-abonnementen = twee verschillende e-mails. Hetzelfde betaalkaartje werkt — het betalingssysteem van Ollama blokkeert geen meerdere abonnementen vanaf dezelfde betaalwijze. Ik heb het gecontroleerd. |
Het hart van het probleem: de Device Key
Wanneer je Ollama installeert, wordt een paar SSH-ed25519-sleutels gegenereerd in de identiteitsdirectory :
$ cat /usr/share/ollama/.ollama/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...Deze sleutel wordt geüpload naar de servers van Ollama wanneer de`ollama signin`. Zij zegt « deze machine behoort tot een Pro-account ». Als uw twee instanties hetzelfde bestand delen`id_ed25519`, ze delen dezelfde identiteit. Einde van het spel.
De parade: ons tweede exemplaar zijn eigen identiteitsdirectory geven, geïsoleerd in een Docker-volume.
Voorbereiding — Stap voor Stap
Vereiste
-
Een werkende native installatie van Ollama (officieel script`curl | sh`)
-
Docker geïnstalleerd en functioneel
-
Portainer of docker-compose voor de implementatie
-
Twee Ollama-accounts met twee verschillende e-mails
Ik heb de versie gebruikt`0.20.2`— die geleverd door het officiële script en de corresponderende Docker-afbeelding.
Stap 1: Maak de Volume
Een eenvoudige map op de host zal dienen als een persistente volume voor de identiteit van instantie B:
mkdir -p ~/ollama-b-dataDeze map wordt gemonteerd in de Docker-container als`/root/.ollama`, daar waar Ollama zijn identiteitssleutels, zijn geschiedenis en zijn modellen opslaat.
Stap 2: Start de 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: alwaysWat hier gebeurt:
-
De haven11435van de host wordt gemapt op de11434interne van de container. Dus, de Docker-instantie luistert op`:11435`zonder conflict met de native instantie die squat`:11434`.
-
het volume`~/ollama-b-data`is gemonteerd op`/root/.ollama`— daar zal de SSH-identiteit worden opgeslagen.
-
`OLLAMA_HOST=0.0.0.0`stelt de container in staat om externe verbindingen te accepteren
Ik heb deze stack via Portainer geïmplementeerd, maar een eenvoudig`docker compose up -d`werkt net zo goed.
Stap 3: Openbare sleutel ophalen
Aangezien de container bij het eerste opstarten leeg is, genereert Ollama automatisch een nieuwe SSH-sleutelpaar in de volume. We halen vervolgens de publieke sleutel op:
$ docker exec ollama-instance-b cat /root/.ollama/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDDQ+dvnfmuo49q5O8LOlvgZ39SKORFw47ry9k4H2jPcIk controleer dat deze sleutel verschillend is van dat van de native instantie:
# 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)Twee verschillende sleutels, twee gescheiden identiteiten. De truc is gespeeld.
|
Als uw container opnieuw wordt gestart, hergebruikt hij de sleutels die aanwezig zijn in het volume. De identiteit is persistent. U zult de koppeling met het Pro-account niet verliezen. |
Stap 4: De sleutel opslaan op Ollama.com
Ga naar https://ollama.com/settings/keys → SSH-sleutel toevoegen. We plakken de publieke sleutel van de Docker-instantie en bevestigen.
Vervolgens koppelen we deze identiteit aan het Pro B-account:
$ docker exec -it ollama-instance-b ollama signinDe browser wordt geopend, we loggen in met de e-mail van account B, en het token wordt gekoppeld aan de SSH-sleutel van de container. We controleren of alles in orde is :
$ docker exec -it ollama-instance-b ollama signin
User: cherolivproStap 5: Testen met een klein gratis model
Voordat ik de prijs van een Pro-abonnement noem, wil ik zeker weten dat de pijp werkt. Ik pull een klein lokaal en gratis model om de connectiviteit te valideren :
$ 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",...}]}De haven`11435`Antwoord, het model wordt geserveerd. Instantie B is levend.
Eenmaal gerustgesteld ga ik over op de pull van het echte Pro-cloudmodel :
$ docker exec ollama-instance-b ollama pull deepseek-v4-pro:cloud
pulling manifest
pulling 31c3059e137e: 100% ▕██████████████████▏ 344 B
success344 bytes voor het manifest van een cloudmodel — normaal, de inferentie vindt server-side plaats, niet lokaal. En daar is de ultieme 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 }
}Hallo aan jou ook, instantie B.
De valstrik van de API `/v1/models
Ik verloor 20 minuten aan een stom detail. Toen ik de provider configureerde.`ollama-b`In OpenCode verscheen niets in de modelkiezer. Niets. Helemaal niets.
De reden ? de API`/v1/models`van instantie B werd geretourneerd`{"object":"list","data":null}`in plaats van`{"object":"list","data":[]}`wanneer geen model werd getrokken. De waarde`null`zorgde ervoor dat de parsing crashte aan de OpenCode-kant, die de provider niet weergeefde.
De oplossing: declareer de modellen expliciet in de OpenCode-configuratie in plaats van te vertrouwen op dynamische ontdekking.
{
"$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)" }
}
}
}
}Met deze expliciete verklaring ziet OpenCode onmiddellijk provider B en zijn modellen. Een herstart van de sessie, en de selector`/models`toont de twee instanties naast elkaar
|
Als u uw aangepaste provider niet ziet in`/models`, Verspil geen drie uur aan het opnieuw opstarten van uw terminal. Verklaar de modellen handmatig in`opencode.json`— dat lost het probleem onmiddellijk op. |
Resultaat: Twee sessies, twee accounts, nul conflict
Uiteindelijk kan ik twee sessies OpenCode tegelijkertijd starten:
Session 1 → /models → Ollama (local) → deepseek-v4-pro:cloud → Compte A
Session 2 → /models → Ollama Instance B (Docker) → deepseek-v4-pro:cloud → Compte BElke sessie heeft zijn eigen quota, zijn eigen rate limit, en staat niet op elkaars tenen. Dezelfde machine, dezelfde blauwe kaart, twee verschillende e-mails.
En het beste? De Docker-container is`restart: always`. Het overleeft de systeemherstarts zonder manuele tussenkomst.
Lessen geleerd
-
Docker isoleert alles, zelfs de identiteit— Een simpele bind mount van een volume is voldoende om een container zijn eigen set SSH-sleutels te geven, waardoor hij ononderscheidbaar is van een andere fysieke machine in de ogen van Ollama.
-
Twee e-mails, dezelfde CB— Ollama blokkeert geen meerdere abonnementen vanaf dezelfde betaalmethode. Alleen het e-mailadres moet verschillend zijn.
-
Gratis testen voordat je betaalt — 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` met
data: nullbreekt OpenCode— Als u een aangepaste provider instelt met`"models": {}`, OpenCode probeert de modellen via de API te ontdekken. Als de API reageert`data: null`, de provider wordt niet weergegeven. Declareer de modellen expliciet. -
Twee accounts, dat is menselijke multi-verwerking— Een Pro-account = een actieve OpenCode-sessie. Twee accounts = twee parallele sessies. Voor iemand die meerdere Gradle-projecten simultaan moet combineren, is dit een game changer.
Om verder te gaan
Artikel gepubliceerd op 2026-05-08