Gemini CLI installeren op een headless VPS
Leer hoe u de Gemini CLI op een headless VPS draait zonder browser. Wij behandelen Node-versiebeheer, rootvrije npm-installaties, API-key authenticatie en tmux voor sessiebehoud.
Wat u bouwt
Een altijd actieve Gemini CLI op een server in uw eigen beheer, bereikbaar via SSH, die langlopende agent-taken uitvoert die doorgaan nadat u uw laptop afsluit. De installatie bestaat uit drie commando's. Het werk zit in alles wat uitgaat van een desktopomgeving: de CLI van Google wil een browser openen voor de aanmelding, maar uw server heeft er geen. Daarom beslaat het grootste deel van deze handleiding het headless-traject: een actuele Node-versie die uw distributie niet standaard levert, een globale npm-installatie waarvoor geen root-rechten nodig zijn, authenticatie zonder browser met een API-key die u buiten uw shell-geschiedenis houdt, en tmux zodat een verbroken SSH-sessie geen actieve taak beëindigt.
Gemini CLI is een open-source (Apache-2.0) Node-programma (@google/gemini-cli) dat communiceert met de Gemini-modellen van Google. Het kan bestanden lezen en schrijven, shell-commando's uitvoeren en tools aansturen in de werkmap. Op een VPS fungeert het als een kleine, altijd beschikbare agent die u aan het werk kunt laten. Daarom zijn het account waaronder het programma draait en de inloggegevens op de server belangrijker dan enige individuele instelling in deze handleiding.
Vereisten en de valkuilen
- Een verse Ubuntu 24.04 KVM VPS met root- of sudo-toegang. Elk KVM-abonnement volstaat; de CLI zelf is licht en verbruikt in ruststand slechts enkele honderden MB aan RAM.
- Node.js 20 of nieuwer. Dit is de harde ondergrens voor de versie; het pakket uit de distributie is verouderd, zie de volgende sectie. Node 20 bereikte op 30 april 2026 het einde van zijn levenscyclus, installeer daarom versie 24.
- Uitgaand HTTPS-verkeer (poort 443) naar de API's van Google. Er zijn geen inkomende poorten nodig; dit is een client, geen server, dus u hoeft geen firewallpoorten te openen.
- Een authenticatiemethode waarvoor geen browser op de server vereist is: ofwel een betaalde Gemini API-sleutel van Google AI Studio, of de Google-inlogprocedure, waarbij u op een headless systeem een code in de terminal plakt. De methode met de API-sleutel is geschikt voor scripts en onbeheerde processen.
- Docker of Podman, alleen als u de
--sandboxisolatie wenst. Dit is optioneel en wordt aan het einde behandeld.
De valkuil waar iedereen momenteel tegenaan loopt, is het accounttype, niet de browser. Google kondigde op 19 mei 2026 aan dat de Gemini CLI vanaf 18 juni 2026 geen verzoeken meer zou verwerken voor abonnees van Google AI Pro en Ultra, en voor gebruikers van de gratis versie. Deze gebruikers worden doorverwezen naar de opvolger, Antigravity CLI (agy). De Gemini CLI werkt nog steeds met betaalde Gemini API-sleutels, API-sleutels voor het Gemini Enterprise Agent Platform en met een Gemini Code Assist Standard- of Enterprise-licentie van een organisatie. Bepaal het authenticatiepad voordat u begint.
Opmerking: het distributiepakket is te oud
Ubuntu 24.04 levert Node 18.19.1 in de eigen repositories, in combinatie met npm 9.2.0. De package.json van de Gemini CLI vereist engines: { node: ">=20" }, en npm blokkeert een mismatch standaard niet; het installeert de software alsnog en toont een waarschuwing die het verschil aangeeft:
npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE package: '@google/gemini-cli@0.50.0',
npm WARN EBADENGINE required: { node: '>=20' },
npm WARN EBADENGINE current: { node: 'v18.19.1', npm: '9.2.0' }
npm WARN EBADENGINE }Als u deze waarschuwing negeert, draait de CLI op een niet-ondersteunde runtime. De applicatie vertoont onvoorspelbaar gedrag of crasht zodra deze een Node 20+ API aanroept die nog niet bestaat. Node 18 bereikte bovendien in april 2025 het einde van de levensduur (EOL), dus dit is in beide gevallen een doodlopend spoor. Installeer een actuele LTS-versie voordat u de CLI installeert. Er zijn twee schone methoden: NodeSource (een systeembrede ondertekende apt-repository) of nvm (een versiebeheerder per gebruiker). Kies er één.
NodeSource, als u wilt dat Node beschikbaar is voor elke gebruiker op het systeem:
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt-get install -y nodejs
node --versionnode --version moet v20.x of hoger weergeven om aan de eisen van de CLI te voldoen, maar Node 20 is sinds 30 april 2026 EOL. Richt u daarom op v24.x, de huidige actieve LTS. Node 26 wordt naar verwachting de actieve LTS op 28 oktober 2026. Controleer de NodeSource-pagina voor het actuele installatiescript; de setup_24.x in de URL is het versienummer dat u moet aanpassen zodra er een nieuwere LTS verschijnt.
nvm, als u Node liever binnen de home-directory van één gebruiker houdt en nooit sudo wilt gebruiken:
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc
nvm install --lts
node --versionDe v0.40.1 in die URL was actueel op het moment van schrijven; controleer de README van nvm voor de meest recente release en vervang het versienummer voordat u het script uitvoert. nvm biedt een aanzienlijk voordeel voor deze taak: het installeert Node en de bijbehorende globale pakketten onder ~/.nvm, waardoor het probleem met rechten bij globale installaties uit de volgende sectie simpelweg niet optreedt. Als u voor de nvm-methode kiest, kunt u de stap voor npm-prefix overslaan.
De CLI installeren zonder sudo npm -g
Het verleidelijke commando is sudo npm install -g @google/gemini-cli. Doe dit niet. Een globale prefix die eigendom is van root veroorzaakt bij elke latere installatie rechtenfouten en laat bestanden in uw npm-cache achter die eigendom zijn van root; dit zal u over enkele maanden problemen opleveren. Voer een standaard (zonder sudo) npm install -g uit op een systeem-Node en u krijgt de andere foutmelding:
npm error code EACCES
npm error syscall mkdir
npm error path /usr/lib/node_modules/@google
npm error errno -13
npm error Error: EACCES: permission denied, mkdir '/usr/lib/node_modules/@google'Dit is npm dat probeert te schrijven naar /usr/lib, waar uw gebruiker geen rechten voor heeft. De oplossing is niet sudo, maar om de globale prefix van npm naar uw home-directory te wijzen, zodat globale installaties op een locatie terechtkomen waar u eigenaar van bent:
mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
npm install -g @google/gemini-cli
gemini --version~/.bashrc, en niet ~/.profile, is een bewuste keuze: tmux, waarbinnen u over twee secties de CLI zult uitvoeren, start een non-login shell die ~/.bashrc leest en ~/.profile overslaat. Een PATH-regel in het verkeerde bestand zorgt er dus voor dat gemini onzichtbaar is op precies de plek waar u het nodig heeft. Als gemini --version een versienummer print, is de test geslaagd. Krijgt u in plaats daarvan gemini: command not found, dan is uw PATH-export niet doorgevoerd; raadpleeg de foutmodi. Bij nvm kunt u de prefix-regels volledig overslaan: deze installeert globale pakketten al in uw home-directory.
Als u op een eerder moment sudo npm heeft uitgevoerd en nu Your cache folder contains root-owned files ziet, herstel dit dan eenmalig met sudo chown -R $(id -u):$(id -g) ~/.npm.
Het probleem met headless authenticatie en hoe dit te omzeilen
Voer gemini de eerste keer interactief uit; de tool biedt aan om u in te loggen met uw Google-account. Op een desktop opent dit een browsertabblad. Op een headless Linux VPS controleert de CLI eerst op een display. Wanneer geen van de variabelen DISPLAY, WAYLAND_DISPLAY of MIR_SOCKET is ingesteld, probeert de tool geen browser te starten. In plaats daarvan toont het een inloglink en wacht het tot u een code terugplakt:
Please visit the following URL to authorize the application:
https://accounts.google.com/o/oauth2/v2/auth?...
Enter the authorization code:Deze procedure werkt via een standaard SSH-verbinding, maar vereist dat u telkens een browser bij de hand heeft. Sinds 18 juni 2026 werkt dit bovendien alleen als uw Google-account wordt ondersteund door de Gemini CLI.
Er zijn twee correcte manieren om dit op te lossen.
De eerste is een API-key; dit is de juiste standaard voor een server. Maak een key aan in Google AI Studio (aistudio.google.com) binnen een project waarvoor facturering is ingeschakeld, aangezien de Gemini CLI geen gratis gebruik meer ondersteunt. Geef deze key door aan de CLI als omgevingsvariabele; de tool leest GEMINI_API_KEY en slaat de browserprocedure volledig over. Let hierbij op het advies om de key buiten uw shell-geschiedenis en wereldwijd leesbare bestanden te houden. Typ niet export GEMINI_API_KEY=AIza... in de prompt, omdat dit in platte tekst in ~/.bash_history terechtkomt, en sla de key niet op in een bestand dat anderen kunnen lezen. Schrijf de key naar een bestand met modus 600 dat de shell bij het opstarten inlaadt:
umask 077
printf 'export GEMINI_API_KEY=%s\n' 'AIzaSyYOUR_KEY_HERE' > ~/.gemini_env
chmod 600 ~/.gemini_env
echo '[ -f ~/.gemini_env ] && . ~/.gemini_env' >> ~/.bashrc
source ~/.bashrcchmod 600 zorgt ervoor dat alleen uw gebruiker het bestand kan lezen. Controleer of de key in de omgeving is geladen met printenv GEMINI_API_KEY; als dit niets weergeeft, valt de CLI terug op de authenticatiekeuze in plaats van de key te gebruiken. De tool leest ook een .env-bestand in ~/.gemini/ als u die indeling verkiest; dezelfde regel geldt, dus gebruik chmod 600 ~/.gemini/.env.
De tweede manier is de Google-inlogprocedure zelf, waarvoor op een headless machine geen tunnel of open poort nodig is. Sinds 18 juni 2026 is dit voornamelijk nuttig voor een Gemini Code Assist Standard- of Enterprise-licentie van een organisatie (stel ook GOOGLE_CLOUD_PROJECT in); gratis persoonlijke accounts en Google AI Pro- of Ultra-abonnementen worden niet langer ondersteund. Start de CLI via een normale SSH-sessie en kies Sign in with Google:
geminiKopieer de getoonde URL naar de browser op uw laptop en geef toestemming. Google leidt door naar https://codeassist.google.com/authcode, waar een autorisatiecode wordt getoond; plak deze bij de Enter the authorization code:-prompt op de VPS om het inloggen te voltooien. Niets op de server wacht op een callback, dus er hoeft geen poort te worden vrijgegeven en geen ssh -L te worden geconfigureerd. OAUTH_CALLBACK_PORT is alleen relevant voor de loopback-procedure die de CLI gebruikt wanneer deze een display detecteert. Als u verbinding heeft gemaakt met X11-forwarding (ssh -X), is DISPLAY ingesteld en kiest de CLI die loopback-procedure, met een redirect naar http://127.0.0.1:PORT/oauth2callback op de server; voer NO_BROWSER=true gemini uit om de code-plakprocedure te forceren. Dit werkt, maar vereist dat u bij een browser zit, waardoor het ongeschikt is voor scripts. Gebruik voor processen die op de achtergrond draaien de API-key.
Stel voor Vertex AI of een Google Cloud-project in plaats van AI Studio GOOGLE_API_KEY in, samen met GOOGLE_GENAI_USE_VERTEXAI=true, of GOOGLE_CLOUD_PROJECT voor een Code Assist-licentie. Hanteer hierbij dezelfde discipline voor omgevingsvariabelen en hetzelfde bestand met modus 600.
Voer het uit in tmux zodat een verbroken SSH-sessie het proces niet beëindigt
Een gemini-proces dat u rechtstreeks vanuit uw SSH-shell start, is een kindproces van die shell. Bij een verbroken verbinding, een dichtgeklapte laptop, wegvallende wifi of een time-out, verbreekt sshd de pseudo-terminal. De shell ontvangt een SIGHUP en beëindigt vervolgens de CLI-taken. Een taak die tien minuten bezig is met het bewerken van bestanden wordt hierdoor afgebroken en bij opnieuw verbinden is er geen proces meer om te herstellen.
tmux lost dit op door de shell te beheren in plaats van dat sshd dit doet. Dit is hetzelfde patroon als het draaien van een AI-coding agent op een externe VPS binnen tmux, en het werkt hier identiek:
sudo apt install -y tmux
tmux new -A -s gemini
# inside the session:
gemini
# detach with Ctrl-b then d, the task keeps running
# reconnect later from any machine:
tmux attach -t geminitmux new -A -s gemini koppelt aan een sessie met de naam gemini als deze bestaat, en maakt deze aan als dat niet zo is. Dit is dus het enige commando dat u direct na elke login hoeft uit te voeren. De shell binnenin behoort toe aan de losgekoppelde tmux-server, niet aan uw SSH-sessie. Als de verbinding wegvalt, blijft de CLI dus gewoon doorwerken. Maak opnieuw verbinding, koppel aan de sessie, en u bent terug op dezelfde plek in uw scrollback. Als u meerdere agent-sessies op één machine draait, één per tmux-sessie, kunnen deze onderling niet communiceren, in tegenstelling tot Claude Code, waarbij één sessie tekst kan doorgeven aan een andere op dezelfde VPS. Houd elke Gemini-taak daarom onafhankelijk of coördineer ze via bestanden op de schijf.
Voor niet-interactieve, gescripte runs heeft Gemini CLI een headless-modus: gemini -p "summarise the failing tests in this repo" print een antwoord en sluit af, en --output-format json geeft machineleesbare output die naar andere processen kan worden gepiped. Headless-modus met een API-key is precies wat u nodig heeft binnen een tmux-sessie die een lange batchtaak uitvoert, of aangestuurd vanuit een cron-taak, met één kanttekening: een cron-taak laadt geen van uw login-bestanden. Geef de crontab-regel daarom zijn eigen GEMINI_API_KEY (of laat het commando ~/.gemini_env sourcen), anders mislukt de uitvoering door een gebrek aan inloggegevens.
Sandboxing en rechten op een server die ook productieomgevingen draait
Een agent met shell-toegang is een shell. De Gemini CLI kan commando's uitvoeren en vraagt standaard om bevestiging bij elk risicovol commando, maar gebruikers grijpen vaak naar --yolo (automatische goedkeuring van elke tool-aanroep). Hierdoor kan de agent bestanden verwijderen, pushen naar git of interne services benaderen met de volledige bevoegdheden van de gebruiker waaronder deze draait. Op een server die ook productieomgevingen draait, is dit een reëel risico met grote gevolgen, geen hypothetisch scenario.
Drie beheersmaatregelen, gerangschikt op effectiviteit:
- Draai de agent als een toegewezen, niet-geprivilegieerde gebruiker. Niet als root, en geen lid van
sudo. Maak eenagent-gebruiker aan met een eigen home-directory, installeer Node en de CLI daar, zodat een verkeerd geïnterpreteerde instructie beperkt blijft tot dat account. Dit is de belangrijkste beslissing die u kunt nemen. - Houd productie-inloggegevens van de server. Geen productie-
~/.aws/credentials, geen.envdie vanaf productie zijn gekopieerd, en geen databasewachtwoord met schrijfrechten voor kritieke systemen. Geef de agent inloggegevens voor een staging-omgeving of alleen-lezen rechten. - Gebruik de ingebouwde sandbox. Met Docker of Podman geïnstalleerd, voert
gemini --sandbox(ofGEMINI_SANDBOX=docker) de tool-aanroepen van de agent uit binnen een container. Deze container mount alleen de huidige projectmap en niet de rest van het bestandssysteem van de host. Dit is geen vervanging voor een niet-geprivilegieerde gebruiker, maar het vormt een sterke tweede laag wanneer dezelfde VPS ook daadwerkelijk productiewerk verricht.
Als u de Gemini CLI naast andere zelfgehoste tools draait, zoals een MCP-server die tools aan de agent op dezelfde VPS aanbiedt, beschouw dan elke toegevoegde functionaliteit als een groter aanvalsoppervlak dat de agent kan bereiken. Beperk de tokens die aan de agent worden verstrekt tot exact één taak.
Quota, kosten en de gekozen authenticatieroute
De authenticatieroute bepaalt hoe u wordt gefactureerd en, sinds 18 juni 2026, of u überhaupt nog toegang krijgt. Vanaf die datum is de Gemini CLI, conform de aankondiging van Google, gestopt met het verwerken van verzoeken voor Google AI Pro- en Ultra-abonnees en voor iedereen die de dienst gratis gebruikte. Dit omvat de gratis laag voor persoonlijke accounts en niet-gefactureerde API-sleutels. De dienst blijft beschikbaar via betaalde Gemini API-sleutels en Gemini Enterprise Agent Platform API-sleutels, waarbij per token wordt afgerekend, en voor organisaties met een Gemini Code Assist Standard- of Enterprise-licentie of andere Google Cloud-toegang, die via Google Cloud worden gefactureerd. Elke laag hanteert nog steeds limieten per minuut en per dag; bij overschrijding retourneren verzoeken een rate-limit-fout totdat het venster wordt gereset.
Twee praktische opmerkingen. Een onbeheerde agent in een lus kan snel uw quotum verbruiken; houd dit de eerste keren in de gaten voordat u de taak toevertrouwt aan een cron job. Als uw reden voor een server-side model privacy of onbeperkte inferentie is in plaats van de gehoste modellen van Google, dan is dat een andere tool. Zelf een open LLM hosten met Ollama op een VPS houdt de gewichten en de prompts op uw eigen machine, ten koste van het draaien van een aanzienlijk kleiner model dan Gemini.
Updates bijhouden
Gemini CLI brengt regelmatig nieuwe versies uit. Omdat u de tool in een prefix onder uw eigen gebruikersaccount heeft geïnstalleerd, is voor updates nooit sudo vereist:
npm install -g @google/gemini-cli@latest
gemini --versionEr zijn verschillende releasekanalen: @latest is de stabiele versie, @preview is de wekelijkse preview, @nightly is de meest recente ontwikkelversie; gebruik @latest voor alles waar u op vertrouwt. Bij nvm bevinden globale pakketten zich onder de actieve Node-versie. Na het uitvoeren van nvm use om van Node-versie te wisselen, moet u de CLI mogelijk opnieuw installeren. Lees de release notes in plaats van elke patch direct te installeren.
Foutmodi, met de exacte strings
npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, gevolgd door een crash van de CLI tijdens runtime. De Node-versie is te oud; de distributie gebruikt 18.19.1, wat tevens het einde van de levenscyclus heeft bereikt. Installeer een huidige LTS-versie via NodeSource of nvm (Node 20 voldoet aan de minimale vereiste van de CLI, maar heeft zelf sinds april 2026 het einde van de levenscyclus bereikt), bevestig dit met node --version, en als u meerdere Node-versies heeft geïnstalleerd, controleer dan of which node naar de nieuwe versie wijst en niet naar /usr/bin/node.
npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. Een globale installatie in een prefix die eigendom is van root. Gebruik geen sudo, stel npm config set prefix ~/.npm-global in, plaats ~/.npm-global/bin op PATH en installeer opnieuw als uw normale gebruiker. Als een eerdere sudo npm cachebestanden heeft achtergelaten die eigendom zijn van root (Your cache folder contains root-owned files), voer dan sudo chown -R $(id -u):$(id -g) ~/.npm uit.
Failed to open browser, of een redirect_uri die wijst naar http://127.0.0.1:PORT die u niet kunt bereiken. De CLI heeft een display-variabele gevonden (vaak vanuit ssh -X) en koos voor de loopback-flow, waarvan de callback op de server uitkomt. Voer NO_BROWSER=true gemini uit om de flow te krijgen waarbij u een code moet plakken, of gebruik het API-key-pad (GEMINI_API_KEY). In een standaard SSH-sessie zou u in plaats daarvan Enter the authorization code: moeten zien; keur de URL goed in de browser op uw laptop en plak de code die Google toont.
Het proces verdween toen de SSH-verbinding werd verbroken. U voerde gemini direct uit vanuit de SSH-shell, waardoor het een kindproces van die shell was en stierf met de pty bij het verbreken van de verbinding. Er is niets te herstellen. Start elke sessie met tmux new -A -s gemini en voer de CLI daarbinnen uit.
Authenticatie mislukt nog steeds terwijl de key is ingesteld, de CLI valt terug naar de authenticatie-kiezer, of een verzoek retourneert API key not valid met HTTP 400. De key bevindt zich niet in de omgeving die de CLI ziet. Bevestig dit met printenv GEMINI_API_KEY; als deze leeg is, werd uw ~/.gemini_env nooit geladen. Controleer of de regel in ~/.bashrc staat, wat interactieve shells (inclusief tmux) lezen, maar cron en andere niet-interactieve shells niet. Een extra spatie of aanhalingsteken in de waarde van de key veroorzaakt ook API key not valid.
429 / RESOURCE_EXHAUSTED / een bericht over een rate-limit. U heeft het quotum bereikt voor de tier die uw authenticatie gebruikt. Wacht tot het venster is gereset, vertraag de agent of stap over op een betaalde API-key. Een agent die vastzit in een retry-loop blijft dit raken; stop de agent en controleer wat deze aan het doen is.
FAQ
Hoe authenticeer ik de Gemini CLI op een headless server?
Gebruik een betaalde API-sleutel in plaats van de browser-login. Maak een sleutel aan in Google AI Studio binnen een project met facturering, sla deze op in een bestand met modus 600 dat uw shell inlaadt (export GEMINI_API_KEY=...), en de CLI slaat het OAuth-browserproces volledig over. Als u in plaats daarvan inlogt met Google, bijvoorbeeld bij een Code Assist Standard- of Enterprise-licentie, toont de CLI op een headless machine een URL; open deze op uw laptop, keur de toegang goed en plak de code die Google toont terug bij de Enter the authorization code:-prompt. Er is geen poort om vast te pinnen en geen tunnel nodig, maar u moet wel fysiek toegang hebben tot een browser, waardoor dit niet geschikt is voor scripts. Persoonlijke gratis accounts worden sinds 18 juni 2026 niet meer ondersteund door de Gemini CLI.
Waarom vraagt een globale npm-installatie om sudo en hoe voorkom ik dit?
Omdat het standaard globale voorvoegsel van npm /usr/lib/node_modules is, waar uw gebruiker niet naar kan schrijven, waardoor een standaard npm install -g faalt met EACCES. De onjuiste oplossing is sudo npm -g, wat resulteert in bestanden die eigendom zijn van root en latere installaties verstoren. De juiste oplossing is om het voorvoegsel naar uw home-directory (npm config set prefix ~/.npm-global) te verwijzen en de bijbehorende bin toe te voegen aan PATH, of gebruik nvm, dat globale pakketten automatisch onder uw home-directory installeert.
Hoe houd ik de Gemini CLI actief nadat ik de verbinding verbreek?
Draai het proces binnen tmux. Een proces dat vanuit uw SSH-shell wordt gestart, stopt wanneer de verbinding wordt verbroken omdat het een kindproces van die shell is; tmux draait de shell onder een losgekoppelde server die de verbreking overleeft. Gebruik tmux new -A -s gemini, voer gemini uit, koppel los met Ctrl-b d en koppel later opnieuw met tmux attach -t gemini.
Is het veilig om de Gemini CLI op een productieserver te draaien?
Alleen met de nodige voorzichtigheid, omdat een agent met shell-toegang alles kan doen wat de gebruiker waaronder deze draait kan doen. Draai de CLI als een toegewezen gebruiker zonder privileges en zonder sudo-rechten, bewaar geen productie-inloggegevens op de machine, vermijd --yolo automatische goedkeuring en gebruik --sandbox (Docker of Podman) om tool-aanroepen te isoleren van de host. Het account waaronder de CLI draait is belangrijker dan welke individuele vlag u ook instelt.
Moet ik firewallpoorten openen voor de Gemini CLI?
Nee. Het is een client die uitgaande HTTPS-aanroepen doet naar de API's van Google; hiervoor is uitgaande poort 443 nodig, maar geen inkomende poorten. De Google-login op een headless machine vereist eveneens geen poort: u plakt een code terug in de terminal in plaats van een callback op de server te ontvangen. Houd inkomend verkeer geblokkeerd.