Octop zelf hosten met Docker Compose: handleiding

Wat Octop is en waarom u het zelf zou hosten

Octop is een zelf-gehoste AI-assistent voor een huishouden of een klein team. De reden om Octop zelf te hosten in plaats van een standaard chat-interface te gebruiken, is dat het gebruikers van elkaar scheidt. Open WebUI biedt een browserinterface voor een model. Octop voegt accounts toe met een beheerdersrol, een privéwerkruimte en een eigen set inloggegevens voor elke gebruiker, evenals een bibliotheek met gespecialiseerde agents waar elke gebruiker per taak tussen kan schakelen. Dat is het verschil waardoor één VPS vijf mensen kan bedienen in plaats van één.

Het project bevindt zich op github.com/TencentCloud/Octop. Het is één proces dat een webdashboard, een command line interface, chatkanalen (Feishu, DingTalk, QQ, Discord, WeCom) en geplande taken aanstuurt, allemaal ondersteund door een enkele SQLite-database onder ~/.octop/. Alles hieronder is geschreven op basis van tag v0.9.19, uitgebracht op 5 augustus 2026. Als u nog twijfelt tussen verschillende platforms, behandelt de vergelijking van Open WebUI-alternatieven die u op een VPS kunt draaien het bredere aanbod.

Eén ding moet duidelijk zijn voordat u hier een avond aan besteedt. Toen deze handleiding werd geschreven, was Octop software van vóór versie 1.0, gepubliceerd vanuit de GitHub-organisatie van een leverancier, met ongeveer 900 sterren in augustus 2026. Sindsdien is op 14 september 2026 versie v1.0.0 getagd, en per 20 oktober 2026 is de nieuwste tag v1.0.2, een stabiele release gepubliceerd op 18 oktober 2026 na een reeks 1.0.2 bèta-tags, waarbij de repository ongeveer 10.400 sterren heeft. De onderstaande stappen zijn geschreven voor v0.9.19 en zijn niet opnieuw getest op 1.x. De ontwikkeling gaat snel, zoals de versienummers aangeven, en niets in deze tekst is een garantie voor een stabiel upgradepad. Pin een tag vast, lees de changelog en houd back-ups bij.

Vereisten voordat u begint

• Een VPS met Ubuntu 24.04, Docker Engine en de Compose-plugin. Bent u nieuw met Compose? Begin dan bij de basisprincipes van Docker Compose voor een VPS.
• git, omdat u een release-tag gaat ophalen in plaats van een image te pullen.
• Een domeinnaam die naar de VPS wijst, omdat u TLS (transport layer security) voor deze service wilt gebruiken.
• Een model-backend die de OpenAI API ondersteunt: een lokale Ollama-instantie, een zelfgehoste gateway of een betaalde API-key.

Octop is op zichzelf licht. Het is een Python-proces en een SQLite-bestand. De belasting wordt veroorzaakt door de model-backend; als u van plan bent het model op dezelfde server te draaien, stem de capaciteit van de server dan af op de behoeften van het model.

Waarom wij de curl-installer niet aanbevelen

De README begint met een installatieopdracht van één regel:

curl -fsSL https://finnie-1258344699.cos.ap-guangzhou.myqcloud.com/octop/install.sh | bash

Wij raden dit af op een server die voor u van belang is, om één concrete reden: dat script bevindt zich niet in de repository. Het wordt geserveerd vanuit een Tencent Cloud Object Storage-bucket. Niets hiervan wordt gedekt door een git-tag of een commit, waardoor u het script van vandaag niet kunt vergelijken met dat van vorige week, en er is geen geschiedenis die een wijziging verklaart. De bucket kan morgen andere bytes serveren en niets in het project zou dat vastleggen. Het resultaat direct naar bash pipen betekent bovendien dat de machine het script uitvoert voordat u er ook maar één regel van heeft gelezen.

De installer schrijft ook naar de host in plaats van naar een container. Het gebruikt uv om Python 3.12 op te halen en een omgeving te bouwen waar uw package manager niets van afweet, waardoor het later verwijderen ervan handmatig werk is.

Er zijn twee betere opties. Haal het script op, lees het door en voer het daarna uit; dit kost u dertig seconden: curl -fsSL <url> -o install.sh, daarna less install.sh, en vervolgens bash install.sh. Of gebruik Docker, wat de rest van deze handleiding beslaat. Het PyPI-pakket (pip install octop) is tenminste een versiebeheerd artefact dat u kunt vastpinnen aan een release.

Octop implementeren met Docker Compose, vastgezet op v0.9.19

Het Compose-bestand dat bij v0.9.19 wordt geleverd, bouwt de image vanuit de repository. In deze handleiding betekent het vastzetten van een versie daarom het uitchecken van een git-tag. Er bestaan wel gepubliceerde images. De v0.9.19-tree bevat al een docker-publish.yml-workflow, toegevoegd in v0.9.8 op 15 juli 2026, die een image bouwt en naar Docker Hub pusht voor elke v*-tag. Sinds 20 oktober 2026 publiceert het project ook naar de container registry van GitHub (docker pull ghcr.io/tencentcloud/octop:1.0.2). Bouwen vanuit de uitgecheckte tag is een striktere vorm van vastzetten, omdat u exact de code compileert die u leest in plaats van te vertrouwen op een registry-tag. Dat is één stap meer dan de meeste zelfgehoste projecten vereisen, aangezien iets als een zelfgehoste AFFiNE-werkruimte vastzet op een gepubliceerde image-tag en niets bouwt op uw VPS. De routine voor clone, checkout en build hieronder is dezelfde als die in de openGym-implementatiehandleiding wordt doorlopen; als u dat eenmaal heeft opgezet, kent u de structuur al.

git clone https://github.com/TencentCloud/Octop.git
cd Octop
git checkout v0.9.19

Dit is de service die het bestand definieert, ingekort tot de relevante onderdelen:

services:
  octop:
    build:
      context: ..
      dockerfile: docker/Dockerfile
    image: octop:latest
    container_name: octop
    restart: unless-stopped
    ports:
      - "${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"
    volumes:
      - ${OCTOP_DATA:-~/.octop}:/data/.octop
    environment:
      - HOME=/data
      - OCTOP_BIND_HOST=0.0.0.0
      - OCTOP_PORT=${OCTOP_PORT:-8088}
      - OCTOP_DEFAULT_PASSWORD=${OCTOP_DEFAULT_PASSWORD:-octop}
      - OCTOP_ADMIN_USERNAME=${OCTOP_ADMIN_USERNAME:-admin}
      - OPENAI_API_KEY=${OPENAI_API_KEY:-}

Let op het build:-blok. image: octop:latest is de naam die uw eigen build krijgt, niet een verwijzing naar een registry, dus latest betekent hier wat u als laatste heeft gecompileerd. Stel het gegevenspad in op een expliciete locatie in plaats van de standaardwaarde te gebruiken, en geef het beheerdersaccount een echt wachtwoord vóór de eerste opstart. Plaats dit in docker/.env:

OCTOP_PORT=8088
OCTOP_ADMIN_USERNAME=admin
OCTOP_DEFAULT_PASSWORD=<a long random password>
OCTOP_DATA=/srv/octop-data

Eén valkuil hier is belangrijker dan de rest van het bestand. Compose leest docker/.env alleen om ${...}-placeholders in de YAML te interpoleren. Een sleutel die u aan dat bestand toevoegt, bereikt de container niet tenzij deze ook onder environment: in het Compose-bestand wordt vermeld. Voeg OCTOP_ACCESS_TOKEN_TTL alleen toe aan .env en er gebeurt helemaal niets, zonder foutmelding. Het alternatief is om dezelfde sleutels in ~/.octop/env te schrijven binnen de gemounte gegevensmap, die Octop bij het opstarten inlaadt. De handleiding over env-bestanden en secrets in Docker Compose legt uit waarom deze twee mechanismen niet hetzelfde zijn.

Bouw en start de service:

docker compose -f docker/docker-compose.yml up -d --build
docker compose -f docker/docker-compose.yml ps
curl http://127.0.0.1:8088/api/health

Een gezonde instantie beantwoordt de health check met een JSON-object in de trant van {"ok":true,"started_at":...,"db":...,"users_loaded":0,"agents_running":0}. Bij iets anders, lees docker compose -f docker/docker-compose.yml logs -f octop voordat u de browser opent.

Geef de image die u zojuist heeft gebouwd nu een betekenisvolle naam, want de volgende --build zal octop:latest overschrijven en u zult de twee niet meer van elkaar kunnen onderscheiden:

docker image tag octop:latest octop:0.9.19

De eerste opstart voert octop init uit en schrijft de initiële inloggegevens naar het gegevensvolume:

docker exec -it octop cat /data/.octop/credential.txt

De standaardwaarden zijn admin / octop, en deze worden alleen bij de eerste initialisatie toegepast. Dat is het mechanisme achter een vraag die mensen constant stellen: het wijzigen van OCTOP_DEFAULT_PASSWORD nadat de container al eenmaal is gestart, verandert niets, omdat het account al bestaat. Wijzig het wachtwoord in plaats daarvan in het dashboard.

Publiceer poort 8088 niet

De regel ports: hierboven bindt aan elke interface op de VPS. Zodra de container start, staat het dashboard op het openbare internet in leesbare tekst, met een standaardwachtwoord. De standaardwaarde van Octop voor OCTOP_BIND_HOST is 127.0.0.1; het Compose-bestand overschrijft dit naar 0.0.0.0 omdat het proces verkeer van buiten de eigen netwerk-namespace moet accepteren. Die overschrijving is correct. De gepubliceerde poort is het onderdeel dat u blootstelt.

Bewerk de regel ports: in docker/docker-compose.yml zodat de mapping alleen luistert op loopback:

    ports:
      - "127.0.0.1:${OCTOP_PORT:-8088}:${OCTOP_PORT:-8088}"

Probeer dit niet op te lossen met een eenvoudig override-bestand. Compose voegt de lijsten ports uit meerdere bestanden samen in plaats van ze te vervangen, waardoor u uiteindelijk beide mappings publiceert en de tweede niet kan binden. Als u het upstream-bestand ongewijzigd wilt laten, gebruik dan de tag !override op de reeks; dit is de gedocumenteerde manier om te vervangen in plaats van toe te voegen. De uitleg over hoe Compose meerdere bestanden samenvoegt behandelt de rest van deze samenvoegregels.

Binden aan loopback lost ook een probleem op waar u anders tegenaan zou lopen met de firewall. Docker schrijft zijn regels voor gepubliceerde poorten naar de nat-tabel vóór de chains die ufw beheert, waardoor ufw deny 8088 een gepubliceerde containerpoort niet blokkeert. Op Docker Engine 28.0.0 of nieuwer is een poort die is gebonden aan 127.0.0.1 niet bereikbaar van buitenaf, ongeacht wat ufw denkt; daarom is dit de juiste oplossing in plaats van een suboptimale. Oudere Engine-releases laten hosts op hetzelfde L2-segment, zoals andere machines op de switch van uw provider, toe om poorten te bereiken die zijn gepubliceerd naar localhost. Voer daarom docker version uit en upgrade als de server een versie lager dan 28 rapporteert.

Plaats TLS voor uw applicatie met een reverse proxy

Caddy is de snelste methode, omdat deze zelfstandig certificaten aanvraagt via ACME (automatic certificate management environment) en WebSockets doorstuurt zonder aanvullende configuratie:

octop.example.com {
    reverse_proxy 127.0.0.1:8088
}

nginx vereist meer aandacht, omdat Octop chatverkeer verstuurt via een WebSocket:

server {
    listen 443 ssl;
    server_name octop.example.com;

    ssl_certificate     /etc/letsencrypt/live/octop.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/octop.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8088;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

Elke regel in dit blok heeft een specifieke functie. Chat verloopt via WS /api/agents/{id}/chat/ws; zonder proxy_http_version 1.1 en de twee upgrade-headers beantwoordt nginx de upgrade-poging met 400 Bad Request. Het dashboard laadt in dat geval normaal, maar elk verzonden bericht blijft oneindig hangen zonder foutmelding op de pagina. proxy_buffering off is van belang omdat het human-in-the-loop resume-eindpunt text/event-stream teruggeeft; zonder deze instelling komen SSE (server-sent events) die in een proxy-buffer worden vastgehouden als één blok aan het einde binnen in plaats van te streamen. proxy_read_timeout is noodzakelijk voor langdurige taken, aangezien de standaardwaarde van 60 seconden een agent halverwege een taak afbreekt en upstream timed out (110: Connection timed out) logt.

Hoe JWT-authenticatie zich gedraagt achter de proxy

Octop authenticeert met een bearer token, niet met een cookie. POST /api/auth/login retourneert {access_token, role, user, ...} en latere aanroepen bevatten Authorization: Bearer <access_token>. Voor een reverse proxy is dat goed nieuws: er is geen cookie-domein, geen Secure-vlag en geen SameSite-regel die fout kan gaan, dus een sessie die werkte op http://127.0.0.1:8088 gedraagt zich hetzelfde op https://octop.example.com.

Twee gevolgen zijn het vermelden waard voordat u echte gebruikers toelaat.

De WebSocket draagt het token in de URL. Het eindpunt is WS /api/agents/{id}/chat/ws?token=<jwt>, omdat browser-JavaScript geen Authorization-header kan instellen bij een WebSocket-handshake. TLS beschermt dat token tijdens het transport. Het beschermt het echter niet tegen uw eigen logs: nginx schrijft standaard de volledige request-regel, inclusief query-string, naar access_log, waardoor een werkend token van een echte gebruiker in een plat tekstbestand op de server belandt. Log het pad zonder de argumenten. $uri is het genormaliseerde pad waarbij de query-string al is verwijderd, dus plaats dit in het http-blok en verwijs er vanuit de server naar:

log_format octop_noargs '$remote_addr [$time_local] '
                        '"$request_method $uri $server_protocol" '
                        '$status $body_bytes_sent';
access_log /var/log/nginx/octop.log octop_noargs;

Er is geen logout per sessie. OCTOP_ACCESS_TOKEN_TTL staat standaard op 86400, dus een token blijft 24 uur na het inloggen geldig. De enige gedocumenteerde manier om een token ongeldig te maken is octop admin rotate-jwt-secret, wat de ondertekeningssleutel opgeslagen op ~/.octop/secrets/jwt_secret roteert en elk uitstaand token onmiddellijk ongeldig maakt voor iedereen. Dus wanneer iemand het team verlaat, is de volgorde: verwijder de gebruiker, roteer het geheim en vraag de overige gebruikers om opnieuw in te loggen. Als dat zwaar klinkt, verkort dan de levensduur, waarbij u eraan denkt de variabele toe te voegen aan zowel de environment:-lijst als .env:

OCTOP_ACCESS_TOKEN_TTL=28800

Brute force wordt afgehandeld: OCTOP_LOGIN_MAX_ATTEMPTS staat standaard op 5 mislukte pogingen en OCTOP_LOGIN_LOCKOUT_SECONDS op 900, dus een buitengesloten gebruiker wacht simpelweg vijftien minuten in plaats van naar een defecte installatie te kijken. Octop heeft zijn eigen gebruikersopslag en geen gedocumenteerde OIDC-ondersteuning in v0.9.19, dus als u echte single sign-on nodig heeft, plaatst u er een authenticerende proxy voor, waarvoor een zelfgehoste Authentik server bedoeld is.

Octop koppelen aan een model-backend

Providers worden per agent geconfigureerd in het dashboard, en octop provider list toont u wat er is ingesteld. Octop wordt geleverd met presets voor OpenAI-compatibele API's, DashScope (Qwen) en Ollama. De inloggegevens worden opgeslagen in de providers-tabel van uw eigen SQLite-database. Uw keuze bepaalt de kosten en welke gegevens uw server verlaten.

Een lokaal model met Ollama. Niets verlaat de server en u betaalt in RAM in plaats van in tokens. Het technische detail waar gebruikers vaak over struikelen: een container kan de Ollama-instantie op de host niet bereiken via 127.0.0.1:11434, omdat dat adres de loopback van de container zelf is. Voeg een host-gateway toe aan de service:

    extra_hosts:
      - "host.docker.internal:host-gateway"

Stel vervolgens de base URL van de provider in op http://host.docker.internal:11434/v1, het OpenAI-compatibele pad van Ollama. Voer een willekeurige niet-lege tekenreeks in als API-sleutel; Ollama negeert deze, maar OpenAI-clients weigeren een lege sleutel te verzenden. Ollama moet ook luisteren buiten de loopback om dit te laten werken; dit vereist OLLAMA_HOST=0.0.0.0:11434 in de systemd-unit. Dit is het risicovolle deel: Ollama heeft geen authenticatie, dus een open poort 11434 op een publiek IP-adres is een gratis modelserver voor iedereen die het netwerk scant. Sta alleen het privé-netwerkbereik van Docker toe, sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp, en blokkeer de rest. Ollama draaien op een VPS behandelt de modelgrootte, en de vergelijking tussen Ollama en vLLM beschrijft wanneer Ollama niet langer de juiste server is.

Nog een waarschuwing voor lokale modellen, omdat het vaak wordt aangezien voor een bug in Octop terwijl dat niet zo is. Agents werken door tools aan te roepen; de systeemprompt, tooldefinities en geschiedenis vormen samen een grote prompt. Ollama serveert modellen met een bescheiden standaard contextvenster, waardoor het begin van de prompt — waar de tooldefinities staan — buiten het venster valt. Het model stopt dan met het aanroepen van tools of verzint tools die niet bestaan. Verhoog num_ctx naar 16k of 32k en kies een model dat daadwerkelijk goed is in function calling. Een antwoord dat halverwege een zin stopt, is een ander probleem met een andere instelling, num_predict. Als antwoorden worden afgebroken, is het de moeite waard om te controleren waar num_predict is ingesteld en wat done_reason aangeeft voordat u de agent de schuld geeft. Als u liever met een specifiek model begint in plaats van een shortlist, is Nemotron 3.5 Lightning het proberen waard. Dat artikel bevat de exacte tag om op te halen, het benodigde RAM-geheugen en of de CPU alleen voldoende is.

Een self-hosted gateway. Plaats een self-hosted LiteLLM-gateway tussen Octop en de rest. U krijgt dan één base URL, een aparte sleutel per gebruiker, bestedingslimieten en één centraal logboek. U kunt ook het model erachter wisselen zonder iets in Octop aan te passen.

Een betaalde API. De hoogste kwaliteit, met een eerlijke afweging: de inhoud van gesprekken verlaat uw server en bereikt de provider, wat haaks staat op het doel van self-hosting. De sleutel wordt ingevoerd in docker/.env als OPENAI_API_KEY, wat het Compose-bestand al doorgeeft.

Welke optie u ook kiest, het Compose-bestand bevat ook OCTOP_LANGFUSE_ENABLED, LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY en LANGFUSE_BASE_URL. Hiermee kunt u traces verzenden naar uw eigen Langfuse-instantie om te zien wat de agents daadwerkelijk doen, in plaats van te gissen op basis van het chatvenster.

Gebruikers, rollen en de gedeelde agent-bibliotheek

Het beheerdersaccount van de eerste opstart creëert en beheert de overige accounts. Elke gebruiker krijgt eigen agents, een eigen werkruimte en eigen inloggegevens. Deze isolatie wordt gewaarborgd door het token dat de browser vasthoudt. Daarnaast is er een gedeelde pool met vaardigheden en sub-agents die voor iedereen toegankelijk zijn. Dit is de functie die het draaien van dit systeem voor een gezin waardevol maakt: één persoon bouwt eenmaal een goede onderzoeks-agent, waarna niemand anders deze opnieuw hoeft te bouwen.

Wees voorzichtig met de tools. Octop adverteert met goedkeuring voor tools en vangrails voor shell-commando's. Beide zijn aanwezig, maar een agent die shell-commando's uitvoert, doet dit binnen de Octop-container met uw datavolume aangekoppeld. Vangrails beperken wat een ondoordachte prompt kan aanrichten. Het zijn geen sandbox-grenzen; laat daarom de goedkeuring voor tools ingeschakeld voor iedereen aan wie u niet zomaar toegang tot een shell zou geven. Als u dit afweegt tegen andere opties, vergelijkt het overzicht van zelfgehoste AI-agents hoe elk systeem hiermee omgaat.

Een project upgraden dat zo snel nieuwe versies uitbrengt

[
  {
    "version": "v0.9.16",
    "days_since_previous_release": 2
  },
  {
    "version": "v0.9.17",
    "days_since_previous_release": 3
  },
  {
    "version": "v0.9.18",
    "days_since_previous_release": 1
  },
  {
    "version": "v0.9.19",
    "days_since_previous_release": 3
  }
]

Dit zijn de datums van de tags uit de repository, geteld op 7 augustus 2026. 4 getagde releases verschenen in negen dagen, met een tussenpoos van slechts 1 dag, en v0.9.19 arriveerde 3 dagen na de voorgaande tag. Dat tempo is een goed teken voor het project, maar een slechte reden om zomaar latest uit te voeren. Lees de wijzigingen door voordat u ze doorvoert:

cd Octop
git fetch --tags
git tag --sort=-creatordate | head
NEW_TAG=$(git tag --sort=-creatordate | head -1)
git log --oneline "v0.9.19..$NEW_TAG"

Controleer wat $NEW_TAG daadwerkelijk bevat voordat u het uitcheckt, omdat het project bètaversies zoals v1.0.2b9 tagt naast stabiele releases. Op 20 oktober 2026 is de nieuwste tag de stabiele v1.0.2, gepubliceerd op 18 oktober 2026, en de sprong vanaf v0.9.19 passeert de v1.0.0-release van 14 september 2026; dat logboek is dus lang en verdient een zorgvuldige lezing.

Maak altijd eerst een back-up, want databasemigraties worden uitgevoerd bij het opstarten en een mislukte migratie bij een project dat zo snel nieuwe versies uitbrengt, is een probleem dat u zelf moet oplossen:

docker compose -f docker/docker-compose.yml stop
sudo tar czf octop-backup-$(date +%F).tgz -C /srv octop-data
docker compose -f docker/docker-compose.yml start

Check vervolgens de nieuwe tag uit en herbouw met docker compose -f docker/docker-compose.yml up -d --build. Als het misgaat, kunt u de oude tag uitchecken en herbouwen om de code te herstellen, maar alleen de tarball herstelt de database.

Die tarball bevat octop.db, config.json, het JWT-ondertekeningsgeheim en credential.txt, dus deze is net zo gevoelig als de server zelf. Bewaar deze met modus 600 en bewaar een kopie buiten de server. Voor een grotere installatie levert het project ook docker/docker-compose.postgres.yml, dat PostgreSQL met pgvector draait in plaats van SQLite.

Foutmodi en bijbehorende meldingen

De health check antwoordt niet. curl http://127.0.0.1:8088/api/health loopt vast of weigert de verbinding. Lees docker compose -f docker/docker-compose.yml logs -f octop. Een container die tijdens de eerste initialisatie afsluit, kan meestal niet naar de datamap schrijven; controleer daarom de eigendomsrechten van het pad dat u bij OCTOP_DATA heeft ingesteld.

Het dashboard laadt, maar de chat loopt vast. Er verschijnt geen foutmelding op de pagina, maar er komt nooit een antwoord. Open de browserconsole en zoek naar een mislukte verbinding met wss://octop.example.com/api/agents/.../chat/ws. De proxy stuurt de upgrade niet door. Voeg proxy_http_version 1.1 en de headers Upgrade en Connection toe.

Het volledige antwoord verschijnt in één keer, met enkele seconden vertraging. Streaming werkt, maar buffering staat aan. Stel proxy_buffering off in.

bind: address already in use. Een ander proces gebruikt al poort 8088. sudo ss -tlnp | grep 8088 toont welk proces dit is. Dit is ook de foutmelding die u krijgt als u een tweede ports-vermelding heeft toegevoegd in een override-bestand in plaats van het origineel te bewerken.

Het juiste wachtwoord wordt geweigerd. Vijf mislukte pogingen leiden tot een blokkade van 900 seconden. Wacht deze tijd af in plaats van de software opnieuw te installeren.

Het nieuwe wachtwoord in .env had geen effect. Deze inloggegevens zijn alleen van toepassing bij de eerste initialisatie. Wijzig het wachtwoord in het dashboard.

De agent antwoordt, maar voert nooit een tool uit. Dit is vrijwel altijd een probleem met het lokale model: het contextvenster is te klein voor de tooldefinities, of het model is niet goed in function calling. Verhoog num_ctx en probeer een model dat specifiek is gebouwd voor het gebruik van tools.

FAQ

Is Octop een vervanging voor Open WebUI?

Alleen als u de extra functionaliteit nodig heeft. Open WebUI is een chatinterface voor een model en voert die taak uitstekend uit voor één persoon of een huishouden dat elkaar vertrouwt. Octop voegt accounts met een beheerdersrol toe, werkruimtes en inloggegevens per gebruiker, en een bibliotheek met gespecialiseerde agents waaruit gekozen kan worden. Hierdoor kunnen meerdere mensen één server delen zonder hun chatgeschiedenis te delen. Als één account voor u volstaat, is Open WebUI de eenvoudigere en veel volwassener keuze.

Waarom zou ik het curl-installatiescript van Octop niet gebruiken?

Het script wordt aangeboden vanuit een Tencent Cloud Object Storage-bucket in plaats van vanuit de repository, waardoor het niet gekoppeld is aan een git-tag of commit. U kunt niet vergelijken wat het vandaag doet met wat het vorige week deed, en het direct doorsturen naar bash voert het uit voordat u het heeft kunnen lezen. Bovendien installeert het zichzelf op de host met een eigen Python 3.12-omgeving, buiten uw pakketbeheerder om. Download het script en lees het eerst door, of implementeer het met Docker Compose vanuit een uitgecheckte tag.

Kan Octop een lokaal model gebruiken in plaats van een betaalde API?

Ja. Octop ondersteunt OpenAI-compatibele API's en bevat een Ollama-preset. Het koppelen aan http://host.docker.internal:11434/v1 werkt zodra u extra_hosts: ["host.docker.internal:host-gateway"] toevoegt aan de container en OLLAMA_HOST=0.0.0.0:11434 instelt op de host. Beveilig poort 11434 met een firewall voor het IP-bereik van Docker, aangezien Ollama zelf geen authenticatie heeft. Houd er rekening mee dat u de num_ctx van Ollama moet verhogen naar 16k of hoger; agent-prompts met tooldefinities overschrijden anders het standaard contextvenster, waardoor het model stopt met het aanroepen van tools.

Heb ik een reverse proxy nodig, of kan ik poort 8088 openstellen?

U heeft de proxy nodig. Het meegeleverde Compose-bestand van Octop publiceert poort 8088 op alle interfaces zonder TLS, waardoor wachtwoorden en bearer tokens in platte tekst over het internet worden verstuurd. Wijzig de gepubliceerde poort naar 127.0.0.1:8088:8088 en plaats Caddy of nginx ervoor met een certificaat. Bij gebruik van nginx moet u de WebSocket upgrade-headers doorsturen en proxy_buffering off instellen, anders laadt de pagina wel, maar reageert de chat niet.

Is Octop klaar voor productie?

Vóór 1.0 werden er per augustus 2026 meerdere getagde releases per week uitgebracht. Op 14 september 2026 werd v1.0.0 getagd, gevolgd door een reeks 1.0.2 bèta-tags vóór de stabiele v1.0.2 op 18 oktober 2026. Dat tempo ligt nog steeds hoog, dus beschouw het als veelbelovend in plaats van stabiel. Dit is werkbaar voor een gezin of een klein intern team als u een specifieke tag vastzet, vóór elke upgrade het commit-logboek leest en vóór elke herbouw een back-up maakt van het datavolume. Draai het nog niet op latest en sla er vooralsnog geen klantgegevens in op.