OneCLI zelf hosten: stappenplan en serververeisten

Wat u krijgt bij het zelf hosten van OneCLI

Host OneCLI zelf en elk teamlid krijgt een eigen agent, die elk in een eigen sandbox draait. De API-keys worden beheerd in een gateway die de agents nooit inzien. De installatie is een Docker Compose-stack met PostgreSQL erachter, bereikbaar op http://localhost:10254. Houd rekening met een volwaardige server. De gedocumenteerde standaard is 2 GiB geheugen per agent-sandbox, dus dit is geen werklast voor een 1 GB VPS.

De stack bestaat uit zeven onderdelen. Het begrijpen van deze onderdelen maakt de rest van deze handleiding leesbaarder.

• Web dashboard (Next.js), poort 10254. Het aanmaken van agents, chat, bewerken van geheugen en vaardigheden, verbindingen en secrets.
• API server, poort 10256. Het controlepaneel: database, afhandeling van gesprekken, werkrijen.
• Rust gateway, poort 10255. Onderschept uitgaande verzoeken van agents en voegt inloggegevens toe.
• Runner. De README beschrijft dit als het onderdeel dat "agent-sandboxes start, parkeert en opruimt. Alleen uitgaand verkeer, en raakt de database nooit aan."
• Sandbox Supervisor. De README beschrijft dit als een proces dat "binnen elke sandbox draait en een leverancier-neutrale interface gebruikt, zodat de agent-runtime uitwisselbaar is."
• Channel adapter. Een daemon die een Slack-app verbindt, zodat een agent in kanalen en DM's onder zijn eigen naam antwoordt.
• PostgreSQL. Het meegeleverde compose-bestand draait postgres:18-alpine met een pgdata volume.

De naam suggereert CLI, het product is een server

OneCLI is een serverplatform. De naam verwijst naar een command-line tool die u op een laptop installeert, maar dat beeld is onjuist voor het product in deze handleiding. Er bestaat wel een afzonderlijke command-line client in de onecli/onecli-cli repository, die het verkeer van een lokale coding agent via een gateway leidt. Wat u hier implementeert is een webapplicatie voor meerdere gebruikers: een accountsysteem waarbij het eerste account eigenaar is van de instantie, een database met gesprekken en geheimen, en een runner die containers start.

Het model per persoon vormt de kern van het ontwerp. Uit de README: "U maakt een agent per persoon, geeft elke agent de benodigde toegang, en deze werkt in een sandbox, geleid door een gateway die de inloggegevens injecteert en uw beleid afdwingt." Elke agent heeft een eigen bestandssysteem en shell, een eigen gespreksinterface, geheugen dat door het platform wordt bewaard, en vaardigheden die u eenmalig schrijft. Inloggegevens werken in tegenovergestelde richting van de gebruikelijke opzet. In plaats van een API-key naar de omgeving van elke persoon te kopiëren, slaat u de key eenmalig op en verleent u toegang aan de agents die deze mogen gebruiken.

Wat de server nodig heeft voordat u begint

• Docker, met de Compose-plugin in versie 2.19 of nieuwer. Het compose-bestand gebruikt een eenmalige migratieservice waar de API op wacht; deze afhankelijkheidsvorm vereist 2.19.
• Geheugen, wat de werkelijke beperkende factor is. Lees de sectie over dimensionering hieronder voordat u een abonnement kiest.
• Vrije loopback-poorten 10254, 10255, 10256 en 5432.

U hoeft PostgreSQL niet zelf te installeren: het compose-bestand voert dit uit als een service. U heeft ook geen Node.js of Rust nodig. Deze zijn alleen bedoeld voor het pad waarbij u vanuit de broncode bouwt, waarbij mise de toolchain vastzet.

Hoeveel agent-sandboxes passen er op uw VPS?

De documentatie van de runner zelf geeft concrete cijfers in plaats van schattingen. Elke sandbox krijgt 2048 MB geheugen (RUNNER_SANDBOX_MEMORY_MB), één CPU (RUNNER_SANDBOX_CPUS) en 512 processen (RUNNER_SANDBOX_PIDS). De limiet voor gelijktijdigheid is 4 (RUNNER_MAX_SANDBOXES), en de documentatie adviseert ongeveer 10 GiB vrij geheugen bovenop de basisstack om die limiet te ondersteunen.

[
  {
    "plan": "2 GB box",
    "ram_gb": 2,
    "sandbox_slots": 0
  },
  {
    "plan": "4 GB box",
    "ram_gb": 4,
    "sandbox_slots": 1
  },
  {
    "plan": "8 GB box",
    "ram_gb": 8,
    "sandbox_slots": 3
  },
  {
    "plan": "16 GB box",
    "ram_gb": 16,
    "sandbox_slots": 7
  },
  {
    "plan": "32 GB box",
    "ram_gb": 32,
    "sandbox_slots": 15
  }
]

Deze aantallen slots zijn gebaseerd op rekenkunde, niet op een benchmark: het totale geheugen, minus ongeveer 2 GB voor PostgreSQL en de vier langlopende services, gedeeld door de sandbox-limiet van 2 GiB. Op basis daarvan biedt het 2 GB box ruimte aan 0 sandboxes, waardoor het goedkoopste abonnement geen hosted agent kan draaien. Een 16 GB box biedt ruimte voor 7, wat comfortabel boven de standaardlimiet van vier ligt en boven de ongeveer 10 GiB vrij geheugen die de runner-documentatie vereist. Het 32 GB box brengt u op 15.

Twee factoren beïnvloeden deze berekening. Een sandbox met een draaiend achtergrondproces wordt nooit geparkeerd, waardoor deze zijn slot permanent bezet houdt. U moet RUNNER_MAX_SANDBOXES daarom dimensioneren op basis van de aanhoudende belasting en niet op basis van het drukste moment. Daarnaast raakt het geheugen eerder op dan de CPU. Elke sandbox is beperkt tot één CPU, dus vier actieve agents vereisen vier cores, maar vier inactieve-maar-actieve agents verbruiken nog steeds 8 GiB.

OneCLI installeren met Docker Compose

De upstream-documentatie voor self-hosting geeft deze exacte volgorde aan. Er worden drie secrets naar docker/.env geschreven naast het compose-bestand, waarna de stack wordt gestart.

git clone https://github.com/onecli/onecli.git && cd onecli/docker
cat > .env <<EOF
SECRET_ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64)
GATEWAY_INTERNAL_SECRET=$(head -c 32 /dev/urandom | base64)
BETTER_AUTH_SECRET=$(head -c 32 /dev/urandom | base64)
COMPOSE_PROFILES=runner
EOF
chmod 600 .env
docker compose up -d --wait

Lees dat blok door voordat u het uitvoert. De heredoc-marker is niet voorzien van aanhalingstekens, waardoor uw shell elke head -c 32 /dev/urandom | base64 uitvoert en het resultaat schrijft in plaats van de letterlijke tekst. SECRET_ENCRYPTION_KEY is de AES-256-GCM-sleutel voor elk geheim in de database. GATEWAY_INTERNAL_SECRET authenticeert de gateway bij de API. BETTER_AUTH_SECRET ondertekent sessiecookies. COMPOSE_PROFILES=runner is de belangrijkste regel, omdat de runner-service zich achter een Compose-profiel bevindt: laat u deze weg, dan start de stack weliswaar correct op, maar zal er nooit een agent-sandbox starten.

--wait houdt de shell vast totdat elke service als 'healthy' wordt gerapporteerd; een non-zero exitcode is dus uw eerste signaal dat er iets mis is. Controleer daarna wat er daadwerkelijk is opgestart.

docker compose ps
docker compose logs migrations

Zet de versie vast. ONECLI_VERSION stelt de tag in voor elke service tegelijk, en de agent-sandbox-image volgt deze tenzij RUNNER_AGENT_IMAGE naar een andere locatie verwijst. Sinds 19 augustus 2026 is de huidige release v2.0.1, gepubliceerd op 18 augustus 2026. Voeg deze toe aan hetzelfde bestand en breng de stack opnieuw omhoog.

echo 'ONECLI_VERSION=v2.0.1' >> .env
docker compose up -d --wait

Er bestaat ook een installer, curl -fsSL https://onecli.sh/install | sh, die de configuratie naar ~/.onecli/.env schrijft en hetzelfde werk verricht. Het Compose-pad is de methode waarbij u elk bestand kunt inzien voordat er iets wordt uitgevoerd, en dit is de aanbevolen methode voor een server die al andere Compose-stacks draait. Bouwen vanuit de broncode is een derde optie, gedocumenteerd als pnpm install en vervolgens pnpm run setup in de gekloonde repository. Dat pad vereist sowieso mise, Rust voor de gateway en Docker, en is bedoeld voor gebruikers die de code willen aanpassen.

Het dashboard bereiken vanaf uw laptop

Elke gepubliceerde poort in het meegeleverde compose-bestand bindt aan ${ONECLI_BIND_HOST:-127.0.0.1}. Op een VPS betekent dit dat het dashboard draait, maar van buitenaf niet bereikbaar is. Die standaardinstelling is correct. Behoud deze en gebruik een tunnel:

ssh -N -L 10254:127.0.0.1:10254 you@your-server

Open nu http://localhost:10254 op uw laptop. Het verkeer verloopt via de SSH-verbinding, waardoor er geen ongecodeerd dashboard op het openbare internet staat en er geen extra poort in de firewall hoeft te worden geopend.

Instelling ONECLI_BIND_HOST=0.0.0.0 publiceert het dashboard via onversleuteld HTTP en publiceert tevens PostgreSQL. Als meerdere personen toegang tot het dashboard nodig hebben, plaats dan een reverse proxy met TLS (transport layer security) voor poort 10254 en wijzig de bind-host niet. Doe dit voordat de instantie een eigenaar heeft. De upstream-documentatie is hierover duidelijk: "Totdat u dit doet, heeft de instantie geen eigenaar en op een bereikbare host wordt de eerste persoon die erbij komt de eigenaar." Als die proxy al voor uw andere zelfgehoste applicaties staat, zorgt forward auth via een zelfgehoste single sign-on laag ervoor dat het dashboard achter de inlogprocedure staat die uw team al gebruikt. Hierdoor wordt de toegang ook direct ingetrokken wanneer u iemand op één centrale plek verwijdert.

Maak het eerste account aan en verleen vervolgens een modelsleutel

Open het dashboard en maak direct het account aan. Dat account is de eigenaar van de instantie; zodra dit account bestaat, is een uitnodiging vereist om deel te nemen.

Sla vervolgens een modelsleutel op voordat u een agent aanmaakt. Een gehoste agent heeft een verleende modelsleutel nodig en de volgorde is hierbij van belang: sla de sleutel op in het dashboard, verleen deze aan de agent en start pas daarna een gesprek. Slaat u het verlenen over, dan zal de sandbox nooit opstarten; dit is zichtbaar als een agent die inactief blijft.

Verleen rechten beperkt. Elke agent krijgt alleen wat u heeft toegewezen en de gateway dwingt dit af bij elk verzoek. Een agent die één repository leest, heeft daardoor geen toegang tot de sleutel van uw betalingsprovider. Dezelfde lijst met verleende rechten is uw middel om de kosten te beheersen. Een agent per persoon die elk model kan aanroepen dat u bezit, resulteert in een factuur per persoon. Het is daarom de moeite waard om te lezen hoe u de uitgaven van een agent voor modelaanroepen kunt beperken voordat u er tien uitdeelt.

Hoe de gateway sleutels buiten de agents houdt

De gateway is een HTTPS-proxy geschreven in Rust, die luistert op poort 10255. De HTTP-client van een agent is hierop gericht en de agent gebruikt een tijdelijke aanduiding (placeholder) in plaats van een echte inloggegevens. De gateway vergelijkt het uitgaande verzoek met de rechten van die agent, ontsleutelt het echte geheim, plaatst dit in het verzoek en stuurt het door. Geheimen staan in PostgreSQL versleuteld met AES-256-GCM (advanced encryption standard, 256-bit, Galois/counter mode) en worden pas ontsleuteld op het moment van het verzoek. Elke aanroep wordt gelogd met de identiteit van de agent en het doel, wat een audit-trail oplevert die u niet kunt krijgen wanneer sleutels in de shell-profielen van tien verschillende personen staan.

Twee mechanismen bepalen hoe u dit implementeert.

• HTTPS-interceptie is een man-in-the-middle. De gateway genereert een lokale certificate authority, de agent vertrouwt deze, en de gateway beëindigt de TLS-verbinding van de agent om vervolgens een nieuwe verbinding te openen naar de upstream-service. Daarom faalt een agent waarvan de HTTP-client de certificate authority van de gateway niet vertrouwt met een certificaatverificatiefout in plaats van een authenticatiefout.
• De agent identificeert zichzelf met een Proxy-Authorization header. Op een enkele machine, waar agents en gateway een intern Docker-netwerk delen, verlaat die header nooit een netwerk dat niet van u is. Richt u een agent van buiten de machine op de gateway, dan heeft de proxy-poort eigen TLS nodig, omdat die header een bearer token is.

De eerlijke afweging: de gateway leest elk verzoek dat uw agents doen, in leesbare tekst, volgens het ontwerp. Het is het meest gevoelige proces op de machine. Behandel de host ervan dienovereenkomstig en houd het aantal mensen dat kan inloggen klein met least-privilege Linux-gebruikers.

Waarom de runner geen inkomende poort nodig heeft

De runner werkt uitsluitend via uitgaand verkeer. Volgens de documentatie: "hij opent geen poorten die van buitenaf bereikbaar zijn, waardoor een laptop, een homelab of een VPC achter NAT allemaal werken zonder inkomend verkeer, tunnels of TLS-termination." NAT staat voor network address translation, de functie die een thuisrouter uitvoert. De runner maakt verbinding met het control plane en haalt daar taken op, dus er hoeft niets te worden doorgestuurd of geopend.

Dit ontwerp werpt zijn vruchten af in het sandbox-netwerk. Het compose-bestand definieert een tweede netwerk gemarkeerd met internal: true, wat in Docker betekent dat er helemaal geen route naar buiten de host is. Sandboxes maken hier deel van uit. De gateway is dual-homed over beide netwerken en is daardoor de enige uitgang. De documentatie van de runner verwoordt dit punt duidelijk: "een internal-netwerk met de gateway dual-homed daarop zorgt ervoor dat uitgaand verkeer via de gateway een harde grens is in plaats van een suggestie." Een agent die besluit uw broncode naar een zelfgekozen adres te sturen, heeft geen route om dit te doen.

Controleer dit op uw eigen systeem in plaats van enkel op de bovenstaande alinea te vertrouwen.

docker network ls
docker network inspect onecli-sandboxes | grep -i internal

U zou "Internal": true moeten zien. Als er false staat, is de controle op uitgaand verkeer uitgeschakeld en is de gateway weer slechts een suggestie. Gebruik de naam van het sandbox-netwerk die docker network ls weergeeft, aangezien onecli-sandboxes slechts de standaardwaarde is.

Hoe sterk is de OneCLI-sandbox?

Lees dit gedeelte aandachtig door, aangezien de term "sandboxed" veel gewicht in de schaal legt in de projectbeschrijving, terwijl het mechanisme op slechts één plek gedocumenteerd is.

De README stelt dat elke agent "zijn eigen geïsoleerde sandbox krijgt, met een bestandssysteem en een shell", en noemt de Sandbox Supervisor als de component die "binnen elke sandbox draait en een leverancier-neutrale harness-interface gebruikt, zodat de agent-runtime vervangbaar is". Geen van beide zinnen specificeert waaruit de isolatie bestaat. De documentatie van de runner doet dit wel: de standaard backend is Docker (RUNNER_BACKEND=docker), en een sandbox is een Docker-container met een geheugenlimiet, een CPU-limiet en een proceslimiet, gekoppeld aan het interne netwerk. De code bevat een interface voor andere backends, en de documentatie noemt zaken als Kubernetes en microVM's als modules die iemand zou moeten schrijven. Vandaag de dag, op uw systeem, is een sandbox een container.

Wat de documentatie niet vermeldt, is even belangrijk. Er is geen dreigingsmodel. Er is geen verklaring over het rootless draaien van de Docker-daemon, over user namespace remapping, over seccomp- of AppArmor-profielen buiten de standaardinstellingen van Docker, en er wordt geen aanspraak gemaakt op een kernel-grens zoals gVisor of een microVM. Hanteer daarom de strikte interpretatie. De limieten zijn resourcelimieten. Het interne netwerk is een daadwerkelijke controle op uitgaand verkeer. De isolatie tussen een agent en uw host is wat een standaard Docker-container biedt, en een container deelt de kernel van de host.

Er is een tweede feit om rekening mee te houden. De runner-service mount /var/run/docker.sock, omdat dit de manier is waarop deze sandboxes aanmaakt. Toegang tot de Docker-socket staat gelijk aan root-toegang op de host, aangezien iedereen die die API kan aanroepen, een container kan starten met het bestandssysteem van de host erin gemount. Elke Docker-gebaseerde runner werkt op deze manier. Het gevolg is dat het runner-proces even gevoelig is als de gateway.

Beschouw de grens als onbewezen totdat de upstream-partij deze documenteert. In de praktijk betekent dit drie gewoontes:

1. Draai OneCLI op een machine die niets anders doet. Geen gerelateerde productieservice, geen gedeelde database, geen data van een ander team.
2. Ga ervan uit dat een agent die willekeurige code-executie binnen zijn sandbox verkrijgt, de host kan bereiken, en zorg dat dit scenario overleefbaar is door back-ups buiten de machine te bewaren.
3. Lees apps/runner/src of vraag het aan de upstream-partij voordat u een collega vertelt dat de agent ingesloten is.

Voor een beeld van hoe een gedocumenteerde grens eruitziet, en de vragen die het waard zijn om aan de upstream-partij te stellen, vergelijkt u dit met hoe een echte agent-sandboxgrens eruitziet. Het verschil zit in het feit of iemand het mechanisme heeft gedocumenteerd en wat het niet tegenhoudt.

De licentiesplitsing en waarom u dit moet controleren voor de bouw

De kern van OneCLI valt onder Apache-2.0 en het zelf hosten hiervan in een productieomgeving is toegestaan. Mappen met de naam ee/ vallen onder een afzonderlijke OneCLI Enterprise License: gratis voor ontwikkeling, testen en evaluatie, waarbij een abonnement vereist is voor productiegebruik. De release notes van v2.0.1 van 18 augustus 2026 vermelden het herstellen van een door GitHub detecteerbaar Apache-2.0 licentiebestand, waardoor de badge op de repository-pagina onlangs is verplaatst. Controleer de tag die u daadwerkelijk implementeert in plaats van een samenvatting die op een andere datum is geschreven.

cd onecli && find . -type d -name ee -not -path '*/node_modules/*'

Alles onder die paden vormt het commerciële gedeelte. Als een functie waar u op wilt vertrouwen zich daar bevindt, bepaal dan de kosten voordat u er een proces omheen bouwt.

Upgrades, migraties en het ene bestand dat u niet mag verliezen

Upgrades zijn een versie-update gevolgd door een herstart. Een eenmalige migratieservice wordt vóór de API uitgevoerd bij elke up. Als een migratie mislukt, weigert de stack te starten in plaats van te werken met een gedeeltelijk gemigreerd schema. Dat is het gewenste gedrag, omdat een mislukte upgrade dan zichtbaar is als een storing in plaats van als stille corruptie, en docker compose logs migrations legt uit waarom.

cd onecli/docker
docker compose pull
docker compose up -d --wait
docker compose logs migrations

Als u in plaats daarvan de installatiescript-methode heeft gebruikt, voer dat script dan opnieuw uit in plaats van handmatig een pull uit te voeren. Zo blijft het compose-bestand in lijn met de images waarnaar het verwijst.

Maak back-ups van twee zaken. PostgreSQL bevat de agents, gesprekken, het geheugen en de versleutelde geheimen. Het bestand docker/.env bevat SECRET_ENCRYPTION_KEY; zonder deze sleutel zijn de versleutelde geheimen onleesbaar, waardoor een database-dump op zichzelf niets bruikbaars herstelt.

cd onecli/docker
docker compose exec -T postgres pg_dump -U onecli onecli | gzip > ~/onecli-db.sql.gz
install -m 600 .env ~/onecli-env.backup

Bewaar beide kopieën buiten de server. De procedure is identiek aan die voor elke stateful Compose-stack. Als u dus al een schema heeft om een Docker Compose-stack te back-uppen en upgraden, voeg dan deze twee paden toe aan uw routine en u hoeft er niet meer naar om te kijken.

Wanneer het niet werkt

• De stack wordt nooit gezond en docker compose up -d --wait sluit af met een non-zero exitcode. Lees eerst docker compose logs migrations, omdat de API bewust wacht op die service.
• Een agent blijft inactief en er verschijnt geen sandbox. Controleer of COMPOSE_PROFILES=runner in docker/.env staat en of docker compose ps een runner vermeldt. Controleer vervolgens of de agent een toegewezen model-key heeft, aangezien sandboxes niet starten zonder een dergelijke sleutel.
• Geen slots meer beschikbaar. RUNNER_MAX_SANDBOXES staat standaard op 4, en een sandbox met een draaiend achtergrondproces houdt zijn slot permanent bezet. docker ps toont wat er daadwerkelijk actief is.
• Containers verdwijnen of de host wordt extreem traag. U heeft een tekort aan geheugen. dmesg -T | grep -i oom registreert out-of-memory kills door de kernel, en een enkele sandbox kan op zichzelf 2048 MB opeisen.
• HTTPS-aanroepen van een agent falen met fouten in de certificaatverificatie in plaats van authenticatiefouten. De HTTP-client vertrouwt de certificaatautoriteit van de gateway niet.
• Oude containers of volumes blijven achter nadat u een agent verwijdert. De runner voert elke 60 seconden een reconciliatie uit en verwijdert weesbestanden die ouder zijn dan RUNNER_ORPHAN_GRACE_SECONDS, wat standaard op 3600 staat. Wacht dus een uur voordat u dit als een lek beschouwt.

Is dit de juiste oplossing voor u?

De fit-test is kort. OneCLI is nuttig wanneer meerdere personen elk een agent nodig hebben en u de inloggegevens op één centrale plek wilt beheren: één opslaglocatie voor rotatie, één auditlogboek om te lezen en één dashboard waar het intrekken van iemands toegang ook daadwerkelijk effectief is. Dit is een reëel operationeel probleem, en het kopiëren van een API key naar zes laptops is daarvoor een inferieure oplossing.

Voor één persoon is het veel techniek voor weinig resultaat. U zou PostgreSQL, een control plane, een gateway en een runner moeten draaien om uzelf van een enkele agent te voorzien, terwijl het probleem met inloggegevens dat de gateway oplost nauwelijks bestaat als u de enige bent die de key bezit. Gebruik in plaats daarvan een enkele harness op een kleinere server: een enkele agent harness op een VPS voert die taak uit met een fractie van het geheugenverbruik. Als u nog geen keuze heeft gemaakt, is het overzicht in zelf-gehoste AI-agents vergeleken de goedkopere eerste stap.

FAQ

Wat zijn de minimale serververeisten om OneCLI zelf te hosten?

Docker met de Compose-plugin versie 2.19 of nieuwer, en voldoende geheugen. PostgreSQL wordt meegeleverd in het compose-bestand, dus u hoeft dit niet afzonderlijk te installeren. Het geheugen bepaalt de keuze voor het abonnement: de runner reserveert standaard 2048 MB per agent-sandbox. De documentatie adviseert ongeveer 10 GiB vrije ruimte bovenop de basisstack om de standaardlimiet van vier sandboxes te ondersteunen, en ongeveer 2 GB voor PostgreSQL en de vier langlopende services. Een server met 4 GB RAM kan één agent tegelijk draaien. Een server met 16 GB RAM dekt de standaardlimiet ruimschoots. Een VPS met 1 GB of 2 GB RAM kan geen gehoste agent starten.

Heeft OneCLI PostgreSQL nodig, of kan het SQLite gebruiken?

Het vereist PostgreSQL. DATABASE_URL is gedocumenteerd als een PostgreSQL-verbindingsreeks, het meegeleverde compose-bestand draait postgres:18-alpine met een pgdata-volume, en een afzonderlijke migratieservice past het schema toe voordat de API start. Er is geen SQLite-optie gedocumenteerd. Als u elders al PostgreSQL draait, verwijs DATABASE_URL dan daarnaar en behoud de migratieservice, aangezien een mislukte migratie de stack stopt in plaats van een half toegepast schema te serveren.

Is de OneCLI-agent-sandbox een echte beveiligingsgrens?

Het gedocumenteerde mechanisme is een Docker-container met geheugen-, CPU- en proceslimieten, gekoppeld aan een netwerk gemarkeerd als internal: true, zodat er geen route naar buiten is behalve via de gateway. De uitgaande controle is effectief en u kunt dit verifiëren met docker network inspect. De isolatie van de host is van container-niveau; de ontwikkelaar publiceert geen dreigingsmodel, claimt geen rootless- of user-namespace-ondersteuning, en biedt geen kernel-grens zoals gVisor of een microVM. De runner mount ook /var/run/docker.sock, wat gelijkstaat aan root-toegang op de host. Beschouw de grens tussen agent en host als onbewezen totdat de ontwikkelaar anders aangeeft, draai OneCLI op een toegewezen server en bewaar back-ups niet op die server.

Moet ik inkomende poorten openen voor OneCLI?

Nee. De runner is alleen uitgaand en luistert niet op poorten die van buitenaf bereikbaar zijn, waardoor het achter NAT werkt zonder tunnel. Het compose-bestand bindt het dashboard, de gateway, de API en PostgreSQL standaard aan 127.0.0.1. Benader het dashboard via een SSH-tunnel, of plaats een reverse proxy met TLS voor poort 10254 als meerdere mensen er toegang toe nodig hebben. De gateway op 10255 is bedoeld voor agents; op een enkele server bereiken die agents de gateway via het interne Docker-netwerk.

Is OneCLI gratis te gebruiken binnen een bedrijf?

De kern is gelicentieerd onder Apache-2.0 en zelf-gehost productiegebruik is toegestaan zonder commerciële licentie. Mappen genaamd ee/ vallen onder de OneCLI Enterprise License, die gratis is voor ontwikkeling, testen en evaluatie, maar een abonnement vereist in productie. De scheiding tussen deze onderdelen verandert tussen releases. De v2.0.1-notities van 18 augustus 2026 vermelden het herstellen van een door GitHub detecteerbaar Apache-2.0-licentiebestand. Controleer daarom LICENSE en de ee/-mappen in de exacte tag die u implementeert voordat u een workflow bouwt op een specifieke functie.