Browserless review: Chrome als een service die je kunt doseren

Browserless is headless Chrome verpakt als een dienst die je zelf host. De Docker-container blijft draaien, verwerkt werk via HTTP of WebSocket en hanteert gedeelde toelatingslimieten in plaats van dat hij in elke caller wordt ingebed. In de REST-tests hier had de service nul Chrome-processen in idle, hij startte Chrome-processen terwijl een request actief was en keerde daarna weer terug naar nul. Wat wordt gedeeld, is servicecapaciteit en wachtrijbeheer — niet een aangetoonde set vooraf opgewarmde browserprocessen.

Ik heb v2.55.0 getest tegen een gecontroleerde lokale fixture — opstarten uitgesplitst in fases, toegangscontrole in drie configuraties, endpoint-gedrag vergeleken met bekende ground truth, een soak van 30 sessies en de timeoutgrens. Het nuttigste gedrag was operationeel en niet zozeer een snelheidswinst: de toelatingslimieten kwamen overeen met de voor de client zichtbare responses, en de scherpe randjes zaten vooral in de deploymentkant.

De meest bruikbare uitkomst was geen latencycijfer. Browserless maakt Chrome niet sneller opstarten — het zet een deurbeleid op Chrome: een vast aantal sessies erin, een wachtrij erachter en een HTTP 429 voor de rest. Die grens verschoof van 4 naar 8 naar 10 toen ik twee omgevingsvariabelen wijzigde, en de administratie van de container kwam bij elke afzonderlijke request overeen met de statuscodes van mijn client.

Wat Browserless eigenlijk is

Hier gaat het vaak al mis bij de categorie. Browserless is geen library die je importeert en aanroept. Het is een Docker-image — ghcr.io/browserless/chromium — dat je als een langdurige service draait. Het bemiddelt browserwerk en stelt dat op twee manieren beschikbaar: REST-endpoints (/content, /scrape, /screenshot, /pdf, plus /function en /unblock) en een CDP/WebSocket-interface waarmee Puppeteer en Playwright kunnen connect()en.

Ik heb de REST-laag getest. De WebSocket-route bestaat echt en wordt veel gebruikt, maar die heb ik niet gemeten.

De geteste versie was v2.55.0, gecontroleerd op 27 juli 2026.

Sterrenaantallen schuiven; zie dit als een momentopname.

De licentiegrens: SSPL-1.0 of commercieel

De repository biedt Browserless aan onder SSPL-1.0 of een commerciële Browserless-licentie. Lees altijd de actuele repository-LICENSE en Browserless’ officiële open-source deployment-richtlijnen voordat je een route kiest. Dit artikel bevat geen juridische analyse van commerciële producten, closed-source applicaties, CI-systemen, gehoste diensten of interne deployments, en kent die scenario’s dus ook geen licentie toe. Laat juristen of de eigenaar van softwarelicenties het deployment- en distributiemodel beoordelen.

Browserless verkoopt ook gehoste plannen. Prijzen en definities van gebruikseenheden zijn veranderlijk en maakten geen deel uit van deze self-hosted test, dus verifieer ze op de officiële site en gebruik een verouderde tabel hier niet als inkoopbewijs.

Hoe het sessiemodel onder de motorkap werkt

Het gemeten REST-pad gedroeg zich als browserwerk per request, maar deze harness traceerde de internals van Browserless niet diep genoeg om een nieuw browserproces te onderscheiden van elke mogelijke context-hergebruikstrategie. Wat wel duidelijk werd, is eenvoudiger: nul Chrome-processen in idle, 11 processen uit de Chrome-familie tijdens een actieve request en weer nul na de sequentiële run. In deze configuratie was er geen bewijs van een vooraf opgewarmde browserpool.

De langdurig draaiende Node-service laat een begrensd aantal browserjobs toe, zet nog een begrensde set in de wachtrij en wijst de rest af. Zie dat toelatingsmodel als het architecturale contract dat hieronder gemeten is. Leid uit het woord “pool” niet af dat processen of contexten worden hergebruikt; deze timing-harness kan dat niet bewijzen.

Toelatingscontrole heeft twee knoppen:

• CONCURRENT — hoeveel sessies tegelijk draaien.
• QUEUED — hoeveel extra requests mogen wachten op een slot.

Het /config-endpoint van de container rapporteerde standaardwaarden van CONCURRENT=10, QUEUED=10, TIMEOUT=30000. Alles boven CONCURRENT + QUEUED wordt direct geweigerd.

Authenticatie is niet optioneel. Browserless v2 vereist altijd een token — als je TOKEN niet instelt, genereert het er een willekeurige en print die bij het opstarten naar stdout. Elke REST-call draagt ?token=.

Voor observability krijg je /pressure (running, queued, CPU, memory, recent geweigerd), /sessions en /config. Er is ook een /metrics JSON-export, maar daarvoor moet METRICS_JSON_PATH gezet zijn en die heb ik niet gebruikt. En de image draait dumb-init als PID 1, wat het gedocumenteerde antwoord is op de klachten over zombieprocessen die containerized Chrome al jaren achtervolgen.

Setup-realiteit: één commando, en vier dingen die niemand in dat ene commando zet

De installregel die iedereen citeert is inderdaad gewoon één docker run. De rest eromheen is waar je op moet plannen.

De image is 4,34 GB. Dat is het getal dat je verwachtingen moet sturen, niet de startup latency. De manifest bevat zowel linux/arm64 als linux/amd64; op mijn arm64-host haalde Docker de native arm64-variant binnen. (Chrome’s user-agent in de container blijft X11; Linux x86_64 tonen — dat is Chrome’s cosmetische UA op Linux, geen emulatie. uname -m zegt aarch64. Hierover worden bugs aangemaakt.)

Ik gebruikte --shm-size=2g voor elke meting. De harness bevatte geen controletest met Docker’s standaard /dev/shm, dus dit artikel kan niet zeggen dat 2 GiB universeel verplicht is of de faalgrens kwantificeren. Stel het af op je browseraantal en workload.

Het token is een deployment-aangelegenheid, geen formaliteit. Zonder token kan iedereen die naar poort 3000 kan routen een browser op je netwerk beheren.

Container-netwerken zijn jouw probleem. Mijn fixture draaide op de host, dus de container bereikte die via host.docker.internal (colima mapte dat met --add-host host.docker.internal:host-gateway). Ik heb eerst met een kale curl gecontroleerd dat de container de fixture echt kon bereiken voordat ik een meting vertrouwde.

Mijn omgeving: colima 0.10.3 (6 CPU / 11,6 GiB) met Docker 29.2.1 op macOS 26.5.2 arm64. De harness gebruikte alleen Python 3 stdlib. Voor PNG en PDF controleerde hij alleen bestandsignaturen, niet decoder-validiteit, afmetingen, aantal pagina’s, volledigheid of visuele getrouwheid.

Een minimale equivalente start gebruikt de vastgezette image, een expliciete token en de hier gebruikte shared-memoryallocatie:

docker run --rm -p 3000:3000 --shm-size=2g \
  -e TOKEN=replace-with-a-secret \
  ghcr.io/browserless/chromium:v2.55.0

Zodra /pressure?token=... antwoordt, test een geauthenticeerde POST /content?token=... met een JSON-body die de doel-URL bevat het REST-pad. Productie-calls hebben ook begrensde retry met jitter nodig voor 429-responses; direct opnieuw proberen betekent alleen dat je opnieuw tegen dezelfde volle wachtrij aanloopt.

De startup-taks, uitgesplitst

Drie verse docker run-starts, mediaan met min–max:

De middelste rij is makkelijk verkeerd te lezen. Dit meet browserstart niet geïsoleerd en laat niet zien dat Browserless Chrome sneller opstart dan een in-proces library. Het is een HTTP-ronde naar een container plus browserwerk, navigatie en response-overdracht. Het verschil van ongeveer 0,17 seconde tussen eerste en latere calls kan filesystem-, OS-, Chrome-, Node- of container-cache-effecten bevatten. Omdat Chrome-processen in idle nul waren en de harness voor deze calls geen CDP-trace of proces-tijdlijn vastlegde, kan die kloof niet worden toegewezen aan browserhergebruik of een “afgeschreven” opstartkost.

Nog iets: dit zijn getallen uit colima-VM op macOS. Bare-metal Linux zal anders uitpakken. Gebruik 0,78 s niet richting je SRE alsof het portable is.

Hands-on: de grens vinden, vanaf beide kanten

Het contract CONCURRENT + QUEUED → 429 wordt overal herhaald en nergens echt gedemonstreerd.

De setup: een fixture-route die server-side 5 seconden slaapt, zodat elke request betrouwbaar één sessie bezet gedurende een bekende tijd. Stuur daarna CONCURRENT + QUEUED + 4 requests tegelijk en kijk wat terugkomt — terwijl een aparte sampler-thread /pressure pollt om de interne administratie van de container te lezen.

Hier kwamen drie dingen uit.

De grens is elke keer exact CONCURRENT + QUEUED. De succesvolle responses waren 4, 8 en 10 — in elk geval de geconfigureerde som. De weigeringen waren gelijk aan de overschrijding, en die was in alle drie runs 4.

De grens verplaatst zich. Het is geen constante die in de image is ingebakken; het is wat jij configureert. Van 4 → 8 → 10 gaan door environment variables te wijzigen is precies wat dit nuttig maakt in plaats van trivia.

En de twee signalen zijn onafhankelijk. De statuscodes van mijn client kwamen uit echte HTTP-responses; /pressure kwam uit de interne administratie van de container, gepolld door een andere thread. In deze drie korte runs kwamen ze overeen. Dat maakt /pressure een kandidaat-productionsignaal, maar niet een volledig autoscaling-contract: scrape-frequentie, resetsemantiek, aggregatie over meerdere replicas en gedrag onder langere gemengde workloads moeten nog worden gevalideerd.

Een nuance die de pass/fail-aantallen verbergen. Een queued request faalt niet — het wacht, en dat kan best lang duren. Bij (2, 2) met 5-secondenwerk kwamen de succesvolle responses ergens tussen 5,7 s en 11,0 s terug, mediaan 8,3 s. End-to-end latency liep dus op tot ongeveer twee sessieduren. De harness legde geen aparte admission- en execution-timestamps vast, dus hij kan de volledige vertraging niet exclusief aan wachtrijtijd toeschrijven.

Hoe dit eruitziet bij een echte job

Stel je rendert elke nacht 4.000 productpagina’s naar PDF, en elke pagina kost ongeveer 5 seconden. Je zet CONCURRENT=5, QUEUED=5. Je throughputplafond is 5 pagina’s per 5 seconden — dus één pagina per seconde — waardoor de job ongeveer 67 minuten duurt als je de pijplijn precies vol houdt. Dat is rekenwerk op gemeten gedrag, geen benchmark, maar wel het rekenwerk dat je moet doen vóór je live gaat.

Elke request die binnenkomt nadat alle running- en queued-slots bezet zijn, kan direct een 429 krijgen; tegelijk uitsturen garandeert niet welke ordinale request de race verliest. Een job-runner moet die response behandelen als backpressure en bounded retry met jitter gebruiken. Anders riskeert hij pagina’s te verliezen terwijl de hogere jobadministratie gewoon doorgaat — een operationeel risico, geen faalscenario dat deze harness heeft aangetoond.

Hands-on: wat de endpoints echt zien

Om render-getrouwheid eerlijk te testen, verstopt de fixturepagina zijn markertekst voor iedereen die geen echte browser draait. De zichtbare string Runtime Injected Marker 88 wordt bij het laden samengesteld uit JavaScript-fragmenten, dus er bestaat geen aaneengesloten letterlijke representatie ervan in de bytes die de server verstuurt. Een statische fetch van die pagina levert 702 bytes op zonder een van beide markers.

Dat /content 811 bytes teruggeeft met de geïnjecteerde marker betekent dat een echte Chromium de pagina heeft gerenderd voordat de HTML terugkwam. /scrape haalde een waarde uit een node die pas bestaat nadat JavaScript draait. Beide werkten met nul client-side automatiseringscode — één geauthenticeerde POST.

Dat is de echte belofte. In dezelfde testronde miste een statische crawler dit soort content volledig, en de in-proces browserlibraries (chromedp, rod, Selenium) kregen het pas te pakken nadat ik een expliciete wait had geschreven. Browserless ving het af met een request in curl-stijl. Je ruilt automatiseringscode in voor deploymentgewicht.

Twee grenzen aan die claim. Het bewijs heeft betrekking op de contenttypes van mijn fixture, niet op een survey van het moderne web. En /unblock, het anti-detectie-endpoint, is bewust met rust gelaten — geen van deze resultaten moet gelezen worden als een anti-bot-capaciteitsclaim. /function, /download en /performance zijn ook niet getest.

Hands-on: een korte residucheck

Containerized Chrome heeft de reputatie lijken achter te laten, dus ik draaide 30 sequentiële sessies met CONCURRENT=3 en telde processen binnen de container.

Voordat ik iets vertrouwde, kalibreerde ik de detector. Terwijl een sessie liep, telde de /proc-enumerator 11 processen uit de Chrome-familie (browser, zygote, GPU, renderers, utilities). Dat is belangrijk: het bewijst dat het instrument Chrome ziet, zodat de nul na afloop een meting is en geen blindheid. Een leak test die “0 processen” meldt zonder te bewijzen dat hij kan tellen, is waardeloos.

Na 30 sessies: 0 Chrome-processen, 0 zombies. De enige overlevenden waren dumb-init, node, Xvfb, start.sh en sh. /sessions las 0 in idle.

Containergeheugen, uit docker stats (het voor de operator zichtbare getal, niet de RSS van één proces):

Netto groei over 30 sessies: ongeveer 9,5 MB, en de gesamplede curve vlakte af na sessie 10. Dat strookt niet met een simpele lineaire per-sessie leak over dit korte venster. Node-warmup is één plausibele verklaring, maar iets wat deze proces- en geheugentijdreeks niet kan bewijzen.

Scope: 30 sequentiële sessies is een kleine soak, geen endurance- of concurrency-run. De al langer bekende EventEmitter-listenerwaarschuwingen in de issue tracker zijn het soort probleem dat pas na uren en duizenden sessies zichtbaar kan worden, en dat heb ik niet gedraaid. De ondersteunde conclusie is alleen dat in dit venster op v2.55.0 geen accumulerende Chrome-processen of zombies zijn waargenomen.

De timeoutgrens

TIMEOUT is gedocumenteerd als een knop. Ik wilde zien dat hij echt afgaat.

Met TIMEOUT=5000 gaf een sessie die een pagina 15 seconden probeerde vast te houden op 5,007 s HTTP 408 terug in plaats van te blijven hangen. Deze ene observatie bevestigt handhaving dicht bij de geconfigureerde grens. Ze onthult niet hoe de timer is geïmplementeerd en bewijst ook geen cleanup van slots; een sterkere test zou de proef herhalen, /sessions en /pressure terug naar idle observeren en daarna bevestigen dat een volgende request het vrijgekomen slot krijgt.

De migratieval: PREBOOT is inert, en het vertelt het je niet

Van alles wat ik heb gemeten, is dit het resultaat dat ik het liefst vóór een upgrade had gekregen.

Browserless 2.0.0 heeft PREBOOT en KEEP_ALIVE verwijderd — de changelog zegt dat ze zijn geschrapt omdat ze verwarrend waren, weinig deden en bugs veroorzaakten. Begrijpelijk. Het probleem ontstaat wanneer een v1-config één-op-één naar v2 wordt gekopieerd, en dat is precies hoe de meeste mensen upgraden.

Ik draaide de container met -e PREBOOT=true en vergeleek dat met de standaardinstelling:

Alle timings zitten binnen de eigen min–max-band van de standaardarm — het is ruis, geen effect. En er was niets vooraf opgewarmd: de container met PREBOOT=true staat idle zonder ook maar één browser vast te houden, identiek aan een container zonder die vlag. Nog twee signalen, maar niet in cijfervorm:

• /config exposeert helemaal geen preboot-key. De keys zijn concurrent, queued, timeout, token, maxCPU, maxMemory, retries en andere.
• Geen fout. Geen waarschuwing. Niets in de containerlogs.

Dus een v1-PREBOOT-config op v2 is bij gewone startup en logchecks een stille no-op. De ontbrekende /config-key plus onveranderde werking vormen het detecteerbare signaal; Browserless geeft geen expliciete weigering of waarschuwing. Een migratiecheck moet toegepaste configuratie inspecteren in plaats van een groene startup te zien als bewijs dat elke omgevingsvariabele effect had.

KEEP_ALIVE is het tegenovergestelde geval, en die twee moet je niet op één hoop gooien. Die is in dezelfde release verwijderd, maar is niet stil — een steekproef van de container laat zien dat hij Environment variable of "KEEP_ALIVE" is deprecated and ignored. direct naar stdout logt. Dat is een nette waarschuwing voor de operator. Ik heb KEEP_ALIVE niet door dezelfde gemeten harness gehaald als PREBOOT, dus ik rapporteer dit als controle, niet als meting. Maar de richting is duidelijk genoeg om ertoe te doen: alleen PREBOOT is de stille valkuil. Browserless is eerlijker over KEEP_ALIVE dan een algemene samenvatting als “v2 negeert je v1-flags” zou doen vermoeden.

Voor- en nadelen

Voordelen

• Toelatingscontrole die exact werkt zoals gedocumenteerd en meebeweegt met de configuratie — bewezen bij drie verschillende plafonds, tegelijk op clientstatuscodes en de eigen serveradministratie.
• /pressure kwam in drie korte runs overeen met de client-zichtbare aantallen running, queued en rejected; zie het als één mogelijke input voor autoscaling en alerting.
• Echt Chromium-rendering zonder client-side automatiseringscode: één geauthenticeerde POST liet JS-injected DOM zien die een statische fetch van dezelfde pagina niet kan zien.
• Geen accumulerende Chrome-processen waargenomen in een sequentiële run van 30 sessies; de post-run telling was 0 Chrome-processen en 0 zombies.
• Eén TIMEOUT-proef gaf 408 terug op 5,007 s tegen een budget van 5,000 s; cleanup en slotvrijgave zijn niet apart geverifieerd.
• Auth standaard aan: alle vier REST-endpoints geven zonder token 401 terug.
• Eén docker run naar een klaarstaande service in ongeveer 0,78 s, en een eerste render 0,32 s daarna.

Nadelen

• Image van 4,34 GB. Dat is de eerlijke headline-kost, en die zie je terug in je registry, je CI-cache en je cold-deploytijd.
• SSPL-1.0 of commerciële Browserless-licentie. Beoordeel de exacte huidige voorwaarden tegen je deployment- en distributiemodel.
• PREBOOT uit v1 wordt op v2 geaccepteerd en stilzwijgend genegeerd — geen fout, geen waarschuwing, geen /config-key.
• Je runt een service, je voegt geen dependency toe: een container, een token, een netwerkpad, een toelatingsgrens en upgradeverantwoordelijkheid.
• Gequeuede requests duwden de end-to-end latency in de (2, 2)-run naar ongeveer twee sessieduren; afzonderlijke wachttijd in de queue is niet gemeten.
• De gemeten REST-timing bevat een HTTP-hop en isoleert de browserstartkost niet en bewijst ook geen browserhergebruik.

Voor wie dit wel en niet geschikt is

Browserless is zijn gewicht waard wanneer meer dan één ding een browser nodig heeft. Een renderdienst die gedeeld wordt door meerdere apps, een team dat screenshots en PDF’s achter een HTTP-endpoint wil in plaats van een Chrome-dependency in elke service, een jobpipeline die echt een capaciteitsgrens met meetbare backpressure nodig heeft — dat is precies het profiel waarvoor dit geschikt is. Als je al Docker draait en iemand verantwoordelijk is voor deployments, is het operationele verhaal helder: voorspelbare toelating, observeerbare backpressure en geen accumulerende Chrome-processen of zombies in de sequentiële check van 30 sessies.

Het is ook de juiste keuze als het alternatief is dat elke service in je stack z’n eigen Chromium installeert. Dat centraliseren in één container met een token en een plafond is architectonisch gewoon een goed ruilmoment.

Sla het over als je één script schrijft. 4,3 GB ophalen en een container draaien zodat één Python-bestand een gerenderde pagina kan ophalen, is veel ceremonie voor een klein klusje — een browserlibrary in je proces doet dat zonder aparte servicedeployment. Sla het over als de SSPL-voorwaarden niet passen bij je commerciële product en je ze niet kunt oplossen. Sla het over als je eigenlijk een browser zoekt die al warm staat zonder cold cost, want PREBOOT geeft je dat op v2 niet. En sla het over als je echte probleem anti-bot-handling is, want die zit in een endpoint dat ik bewust niet getest heb en waar ik mijn hand niet voor in het vuur steek.

Alternatieven, inclusief waar Thunderbit past

De vergelijking die je hier moet maken is niet Browserless versus nog een container. Het gaat erom waar de browser draait en wie verantwoordelijk is om hem in leven te houden.

Gerelateerde review: Browsertrix Crawler review.

Gerelateerde review: chromedp review.

Als je een browser in je eigen proces wilt en het schrijven van waits geen probleem vindt, is een library lichter en heb je geen deployment nodig. Ik heb die kant beschreven in de Playwright versus Puppeteer-vergelijking en in de bredere round-up van open-source scrapingprojecten.

Als je helemaal geen browser wilt beheren, is onze eigen Thunderbit een beheerd alternatief. Browserless geeft gerenderd materiaal terug dat jouw code interpreteert; Thunderbit kan Markdown of schema-matched data teruggeven terwijl de provider de render-infrastructuur beheert. Dit artikel heeft Thunderbit niet gebenchmarkt op latency, capaciteit, faalgedrag, extractiekwaliteit of kosten, dus de tabel beschrijft verantwoordelijkheidsgrenzen en geen prestatievergelijking.

Gerelateerd leesvoer uit dezelfde testronde: de Crawl4AI review behandelt een browser-backed Markdown-pijplijn die je zelf draait, en het overzicht van webscrapingtools zet de bredere categorie neer.

Probeer Thunderbit voor webdata-extractie

Eindoordeel

Moet je Browserless draaien? Ja, als meerdere afnemers browserwerk nodig hebben, iemand de container kan beheren en je licentiecheck het deploymentmodel goedkeurt. In drie synthetische toelatingsruns kwam het aantal geaccepteerde requests overeen met CONCURRENT + QUEUED, overschrijding kreeg 429 en /pressure sloot aan bij de voor de client zichtbare aantallen. In een aparte sequentiële check van 30 sessies stapelden geen Chrome-processen of zombies zich op. Eén timeoutproef gaf rond de geconfigureerde grens 408 terug. Dat zijn nuttige, begrensde observaties — geen universele garanties.

Wees wel eerlijk over de inzet. Het is een image van 4,34 GB en een service die je beheert, geen dependency die je toevoegt; deze test toonde geen snelheidsvergelijking met een in-proces browserlibrary. Wat je ervoor terugkrijgt, is een browser die je kunt rantsoeneren: een bekende grens en meetbare backpressure. In de sequentiële check van 30 sessies werden geen accumulerende Chrome-processen of zombies waargenomen. De kosten zijn deploymentgewicht en een licentie die je moet lezen. Als je een handvol pagina’s uit één script rendert, betaalt die ruil zich niet terug. Als je een renderinglaag runt waar meerdere services op leunen, dan wel — maar check onderweg je v1-omgevingsvariabelen, want PREBOOT ziet er werkloos uit maar doet op v2 helemaal niets.

Probeer Thunderbit voor webdata-extractie Get Started Free

Veelgestelde vragen

Maakt Browserless headless Chrome sneller?
Deze test kan dat niet beantwoorden. Het HTTP-endpoint reageerde 0,78 s na docker run; de eerste /content-call duurde daarna 0,32 s en latere calls in dezelfde container ongeveer 0,15 s. Die cijfers combineren een HTTP-ronde, browserwerk, navigatie en response-overdracht. De harness isoleerde launchtijd niet, traceerde geen process-hergebruik en publiceerde geen vergelijkbare in-proces benchmark. Gebruik Browserless voor een gedeelde servicerand en toelatingscontrole, en benchmark vervolgens je eigen latency-pad.

Wat gebeurt er als je Browserless’ concurrency-limiet overschrijdt?
Je krijgt direct HTTP 429. De grens is exact CONCURRENT + QUEUED, en ik heb dat op drie configuraties bevestigd: (2,2) accepteerde 4 en weigerde 4, (3,5) accepteerde 8 en weigerde 4, (5,5) accepteerde 10 en weigerde 4. Het /pressure-endpoint van de server gaf elke keer overeenkomende running-, queued- en recentlyRejected-aantallen. Goed om te weten: gequeuede requests falen niet, ze wachten — bij (2,2) met 5-secondenwerk duurden succesvolle responses tussen 5,7 s en 11,0 s. Bouw je client dus zo dat 429 als backpressure met retry en backoff wordt behandeld.

Werkt PREBOOT nog in Browserless v2?
Nee. PREBOOT is in 2.0.0 verwijderd, en v2 accepteert -e PREBOOT=true zonder fout of waarschuwing, maar doet er niets mee. Ik heb die inertie op drie manieren bevestigd: de latency was niet te onderscheiden van de standaardinstelling, een idle container met PREBOOT=true had 0 Chrome-processen klaarstaan en /config toont helemaal geen preboot-key. Als je een v1-config hebt gemigreerd, zijn je instances niet vooraf opgewarmd. Let op dat KEEP_ALIVE, dat in dezelfde release is verwijderd, wél een waarschuwing deprecated and ignored logt — het stille-foutprobleem is dus specifiek voor PREBOOT.

Is Browserless gratis voor commercieel gebruik?
De repository biedt SSPL-1.0 of een commerciële Browserless-licentie, maar dit artikel koppelt geen specifieke commerciële of closed-source scenario’s aan een van beide opties. Controleer de actuele LICENSE en officiële deployment-richtlijnen en laat daarna de persoon die verantwoordelijk is voor softwarelicenties je deployment- en distributiemodel beoordelen.

Laat Browserless zombie-Chrome-processen achter?
In het geteste korte venster niet. Na 30 sequentiële sessies had de container 0 Chrome-processen en 0 zombies, met alleen dumb-init, node, Xvfb, start.sh en sh over. De detector telde 11 Chrome-familieprocessen terwijl een sessie live was, dus hij was niet blind. Containergeheugen ging van 294 MiB naar 303 MiB en vlakte daarna af in de samples. Dit is geen endurance-resultaat van meerdere uren, geen concurrency-run en ook geen test met duizenden sessies.