Recenze Browserless: Chrome jako služba, kterou můžete dávkovat

Browserless je headless Chrome zabalený jako služba, kterou si hostuješ sám. Jeho Docker kontejner běží nonstop, bere úlohy přes HTTP nebo WebSocket a místo toho, aby se importoval do každého volajícího, uplatňuje sdílené limity pro přijímání požadavků. V těchto REST testech služba v nečinnosti držela 0 procesů Chrome, při aktivním požadavku procesy Chrome vytvářela a po dokončení se zase vrátila na nulu. To, co se ve skutečnosti sdílí, je kapacita služby a fronta, ne nějaká ověřená sada předem probuzených browser procesů.

Verzi v2.55.0 jsem testoval v řízeném lokálním prostředí — start rozložený do fází, řízení přijetí ve třech konfiguracích, shodu endpointů s referenční pravdou, soak test na 30 relací a hranici timeoutu. Přínosné chování bylo spíš provozní než rychlostní: limity přijetí odpovídaly odpovědím viditelným pro klienta a ostré hrany byly hlavně dané způsobem nasazení.

Nejužitečnější výsledek nebylo číslo latence. Browserless neurychluje start Chrome — dává na Chrome přístupová pravidla: pevný počet relací uvnitř, za nimi frontu a pro všechny ostatní HTTP 429. Tahle hranice se při změně dvou proměnných prostředí posunula z 4 na 8 a pak na 10, a účtování uvnitř kontejneru se ve všech jednotlivých požadavcích shodovalo se stavovými kódy mého klienta.

Co Browserless ve skutečnosti je

Zde se lidé často pletou v kategorii. Browserless není knihovna, kterou importuješ a voláš. Je to Docker image — ghcr.io/browserless/chromium — který spouštíš jako dlouho běžící službu. Zprostředkovává práci s prohlížečem a zpřístupňuje ji dvěma způsoby: REST endpointy (/content, /scrape, /screenshot, /pdf, plus /function a /unblock) a CDP/WebSocket rozhraním, ke kterému se mohou connect() připojit Puppeteer a Playwright.

Testoval jsem REST rozhraní. WebSocket cesta je reálná a široce používaná, ale neměřil jsem ji.

Testovaná verze byla v2.55.0, ověřená 27. července 2026.

Počet hvězdiček se mění; ber to jako snímek v daném čase.

Licenční brána: SSPL-1.0 nebo komerční licence

Repozitář nabízí Browserless pod licencí SSPL-1.0 nebo komerční licencí Browserless. Před volbou cesty si přečti aktuální repozitářový soubor LICENSE a oficiální doporučení Browserless pro open-source nasazení. Tento článek nedělal právní analýzu komerčních produktů, uzavřených aplikací, CI systémů, hostovaných služeb ani interních nasazení, takže těmto scénářům nepřiřazuje žádnou licenci. Nech právníka nebo osobu odpovědnou za licencování software posoudit model nasazení a distribuce.

Browserless také prodává hostované plány. Ceny a definice jednotek použití se často mění a nebyly součástí tohoto self-hosted testu, proto si je ověř na oficiálním webu a neber zastaralou tabulku zde jako podklad pro nákup.

Jak funguje session model uvnitř

Naměřená REST cesta se chovala jako browser práce na každý požadavek, ale tento harness neprohrabal vnitřnosti Browserless dost hluboko na to, aby rozlišil nový browser proces od jakéhokoli mechanismu znovupoužití kontextu. Co ale ukázal jasně, je jednodušší: v klidu 0 procesů Chrome, během aktivního požadavku 11 procesů z rodiny chrome a po sekvenčním běhu zase nula. V téhle konfiguraci nebyl důkaz o předem zahřátém browser poolu.

Dlouho běžící Node služba přijímá omezený počet browser úloh, další omezený počet dá do fronty a zbytek odmítne. Tenhle model přijetí ber jako architektonický kontrakt změřený níže. Z toho, že se používá slovo „pool“, nevyvozuj znovupoužití procesů nebo kontextu; časovací harness to neumí prokázat.

Řízení přijetí má dvě páčky:

• CONCURRENT — kolik relací běží současně.
• QUEUED — kolik dalších požadavků může čekat na volné místo.

Endpoint /config v kontejneru hlásil výchozí hodnoty CONCURRENT=10, QUEUED=10, TIMEOUT=30000. Cokoli nad CONCURRENT + QUEUED je okamžitě odmítnuto.

Autentizace není volitelná. Browserless v2 vždy vyžaduje token — pokud TOKEN nenastavíš, vygeneruje při startu náhodný a vypíše jej na stdout. Každý REST požadavek nese ?token=.

Pro pozorovatelnost máš k dispozici /pressure (běží, ve frontě, CPU, paměť, nedávno odmítnuté), /sessions a /config. Existuje i JSON export /metrics, ale potřebuje nastavený METRICS_JSON_PATH a já jsem ho nepoužil. A image spouští dumb-init jako PID 1, což je zdokumentovaná odpověď na problémy se zombie procesy, které s kontejnerizovaným Chromem roky souvisejí.

Realita setupu: jeden příkaz a čtyři věci, které do něj nikdo nezmiňuje

Instalační řádek, který všichni citují, je opravdu jeden docker run. Všechno kolem něj je to, na co se vyplatí připravit.

Image má 4,34 GB. To je číslo, podle kterého bys měl kalibrovat očekávání, ne podle startup latence. Manifest nese linux/arm64 i linux/amd64; na mém arm64 hostu Docker stáhl nativní arm64 variantu. (Chromeův user-agent uvnitř kontejneru přesto hlásí X11; Linux x86_64 — je to jen kosmetický Linux UA Chrome, ne emulace. uname -m vrací aarch64. Lidé kvůli tomu zakládají bug reporty.)

Pro každé měření jsem použil --shm-size=2g. Harness neobsahoval kontrolní běh na výchozím /dev/shm v Dockeru, takže tento článek nemůže tvrdit, že 2 GiB jsou univerzálně povinné, ani kvantifikovat bod selhání. Velikost nastav podle počtu browserů a zátěže.

Token je provozní záležitost, ne formalita. Bez něj může kdokoli, kdo se dostane na port 3000, ovládat browser ve vaší síti.

Síťování kontejneru je tvůj problém. Moje fixture běžela na hostiteli, takže se k ní kontejner dostával přes host.docker.internal (colima to mapuje pomocí --add-host host.docker.internal:host-gateway). Než jsem uvěřil jakémukoli měření, ověřil jsem prostým curl, že se kontejner k fixture skutečně dostane.

Moje prostředí: colima 0.10.3 (6 CPU / 11,6 GiB) s Dockerem 29.2.1 na macOS 26.5.2 arm64. Harness byl jen Python 3 stdlib. U PNG a PDF ověřoval podpisy souborů, ne správnost dekodéru, rozměry, počet stránek, úplnost ani vizuální shodu.

Minimální ekvivalentní spuštění používá připnutý image, explicitní token a sdílenou paměť nastavenou stejně jako zde:

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

Jakmile /pressure?token=... odpoví, ověřený POST /content?token=... s JSON tělem obsahujícím cílovou URL otestuje REST cestu. Produkční volající navíc potřebují omezený retry s jitterem pro odpovědi 429; okamžité opakování jen znovu běží proti stejné plné frontě.

Daň za start, rozložená na části

Tři čerstvé starty docker run, medián s min–max:

Prostřední řádek se snadno přeceňuje. Neměří start browseru izolovaně a neukazuje, že Browserless startuje Chrome rychleji než knihovna běžící přímo v procesu. Je to HTTP cesta do kontejneru plus práce browseru, navigace a přenos odpovědi. Zhruba 0,17sekundový rozdíl mezi prvním a pozdějšími běhy může zahrnovat efekty souborového systému, OS, Chrome, Node nebo cache kontejneru. Protože při nečinnosti byly procesy Chrome na nule a harness pro tyto volání nezachytil žádný CDP trace ani časovou osu procesů, nelze ten rozdíl připsat znovupoužití browseru ani „amortizované“ ceně startu.

A ještě: tohle jsou čísla z colima VM na macOS. Na čistém Linuxu na železe budou jiná. Neuváděj před SRE číslo 0,78 s jako přenositelné.

Prakticky: hledání stropu z obou stran

Smlouva CONCURRENT + QUEUED → 429 se opakuje všude, ale nikde není pořádně demonstrována.

Nastavení: fixture route, která serverově spí 5 sekund, takže každý požadavek spolehlivě zabere jednu relaci po známou dobu. Pak současně pusť CONCURRENT + QUEUED + 4 požadavků a sleduj, co se vrátí — zatímco samostatné vlákno pro sampling polluje /pressure a čte vlastní účtování kontejneru.

Z toho vypadly tři věci.

Strop je pokaždé přesně CONCURRENT + QUEUED. Úspěšných odpovědí bylo 4, 8 a 10 — tedy vždy konfigurací daný součet. Odmítnutí odpovídala přetečení, které bylo ve všech třech bězích 4.

Strop se posouvá. Není to konstanta zabudovaná do image; je to to, co nastavíš. Přechod 4 → 8 → 10 pouhou změnou environmentálních proměnných je to, co z toho dělá užitečnou vlastnost a ne kuriozitu.

A oba signály jsou nezávislé. Stavové kódy klienta pocházely z reálných HTTP odpovědí; /pressure pocházelo z interního účtování kontejneru, které pollovalo jiné vlákno. V těchto třech krátkých bězích se shodovaly. Z /pressure se tak stává kandidátní produkční signál, ne však kompletní kontrakt pro autoscaling: frekvenci scrape, reset semantiku, agregaci více replik a chování při delší smíšené zátěži je ještě potřeba ověřit.

Jeden detail, který počty úspěchů/neúspěchů zakrývají. Požadavek ve frontě nepadá — čeká, a někdy dost dlouho. Při (2, 2) a pětisekundové práci dorazily úspěšné odpovědi mezi 5,7 s a 11,0 s, medián 8,3 s. End-to-end latence tedy dosahovala zhruba dvou délek relace. Harness nezachytil samostatné časové značky přijetí a exekuce, takže nemůže celý delay připsat jen čekání ve frontě.

Jak to vypadá na reálné úloze

Představ si, že každou noc renderuješ 4 000 produktových stránek do PDF a každá stránka trvá asi 5 sekund. Nastavíš CONCURRENT=5, QUEUED=5. Tvoje stropní propustnost je 5 stránek za 5 sekund — tedy jedna stránka za sekundu — takže úloha zabere asi 67 minut, pokud potrubí udržíš přesně plné. Je to aritmetika z naměřeného chování, ne benchmark, ale je to přesně ta aritmetika, kterou bys měl dělat před nasazením.

Jakýkoli požadavek, který dorazí poté, co jsou vyčerpány všechny běžící i frontové sloty, může okamžitě dostat 429; současné odeslání nezaručuje, který pořadový požadavek prohraje závod. Runner by měl na tuto odpověď pohlížet jako na backpressure a používat omezený retry s jitterem. Jinak riskuje, že bude zahazovat stránky, zatímco vyšší vrstva job accounting dál běží — provozní riziko, ne chybový scénář, který tento harness prokázal.

Prakticky: co skutečně vidí endpointy

Aby bylo možné poctivě testovat věrnost renderu, fixture stránka skrývá svůj marker text před každým, kdo neběží opravdový browser. Viditelný řetězec Runtime Injected Marker 88 se při načtení skládá z JavaScript fragmentů, takže v žádném bajtu poslaném serverem neexistuje jako souvislý literál. Prostý statický fetch té stránky vrátí 702 bajtů, které neobsahují ani jeden marker.

To, že /content vrací 811 bajtů s vloženým markerem, znamená, že stránku před vrácením HTML skutečně vyrenderoval Chromium. /scrape vytáhl hodnotu z uzlu, který vznikne až po spuštění JavaScriptu. Obojí fungovalo s žádným klientským automatizačním kódem — jen jeden autentizovaný POST.

A to je skutečný prodejní argument. Ve stejném kole testování statický crawler tuto třídu obsahu minul úplně a in-process browser knihovny (chromedp, rod, Selenium) ji zachytily až poté, co jsem dopsal explicitní wait. Browserless to zachytil požadavkem ve stylu curl. Vyměňuješ automatizační kód za provozní váhu.

K těmto tvrzením ale dvě hranice. Důkazy pokrývají typy obsahu z mojí fixture, ne průzkum moderního webu. A /unblock, endpoint proti detekci, jsem záměrně nechal být — žádné z těchto výsledků neber jako tvrzení o anti-bot schopnostech. /function, /download a /performance také nebyly testovány.

Prakticky: krátká kontrola zbytků

Kontejnerizovaný Chrome má pověst, že po sobě zanechává mrtvoly, takže jsem spustil 30 sekvenčních relací s CONCURRENT=3 a uvnitř kontejneru počítal procesy.

Než jsem čemukoli věřil, kalibroval jsem detektor. Zatímco jedna relace běžela, enumerátor /proc napočítal 11 procesů rodiny chrome (browser, zygote, GPU, renderery, utility). To je důležité: dokazujeme tím, že nástroj Chrome skutečně vidí, takže jeho nulový výsledek po běhu je měření, ne slepota. Leak test, který hlásí „0 procesů“, aniž by prokázal, že umí počítat, je k ničemu.

Po 30 relacích: 0 procesů chrome, 0 zombie procesů. Jediné přeživší procesy byly dumb-init, node, Xvfb, start.sh a sh. /sessions v klidu ukazovalo 0.

Paměť kontejneru podle docker stats (číslo viditelné pro operátora, ne RSS jednoho procesu):

Čistý růst za 30 relací: asi 9,5 MB a křivka v datech se po 10. relaci ustálila. To je neslučitelné s jednoduchým lineárním únikem na relaci v tomto krátkém okně. Jedno možné vysvětlení je zahřívání Node, ale z počtu procesů a paměťové řady to nelze prokázat.

Rozsah: 30 sekvenčních relací je malý soak, ne endurance ani concurrency test. Dlouhodobě známá varování EventEmitter listenerů v issue trackeru jsou přesně ten typ problému, který se může projevit až po hodinách a tisících relací, a to jsem netestoval. Podporovaný závěr je jen to, že v tomto okně na v2.55.0 nebylo pozorováno hromadění procesů Chrome ani zombie procesů.

Hranice timeoutu

TIMEOUT je podle dokumentace jeden z parametrů. Chtěl jsem vidět, že skutečně zabere.

S TIMEOUT=5000 relace, která se snažila držet stránku 15 sekund, vrátila HTTP 408 po 5,007 s místo toho, aby visela. To jediné pozorování potvrzuje enforcement poblíž nastavené hranice. Neodhaluje implementaci časovače ani neprokazuje úklid slotu; silnější test by relaci opakoval, sledoval návrat /sessions a /pressure do klidu a pak potvrdil, že následující požadavek uvolněný slot skutečně obsadí.

Migrační past: PREBOOT je neaktivní a nic ti neřekne

Ze všeho, co jsem měřil, je tohle výsledek, který bych si před upgradem přál dostat jako první.

Browserless 2.0.0 odstranil PREBOOT a KEEP_ALIVE — changelog říká, že byly odstraněny, protože byly matoucí, moc nepomáhaly a způsobovaly chyby. Rozumné rozhodnutí. Problém nastává, když se config z v1 prostě zkopíruje do v2, což je nejběžnější způsob upgradu.

Spustil jsem kontejner s -e PREBOOT=true a změřil ho proti výchozímu nastavení:

Všechna časování leží uvnitř min–max pásma defaultní větve — je to šum, ne efekt. A nic nebylo předem zahřáté: kontejner s PREBOOT=true je v klidu bez jakýchkoli browserů, stejně jako ten bez tohoto příznaku. Další dva signály, ani jeden z nich není číslo:

• /config vůbec nevystavuje žádný klíč preboot. Klíče jsou concurrent, queued, timeout, token, maxCPU, maxMemory, retries a další.
• Žádná chyba. Žádné varování. Nic v logu kontejneru.

Takže v1 konfigurace PREBOOT na v2 je v běžném startu a kontrole logů tichý no-op. Chybějící klíč v /config plus nezměněné chování je detekovatelný signál; Browserless nevypíše explicitní odmítnutí ani varování. Migrační kontrola musí zkoumat skutečně aplikovanou konfiguraci, ne brát zelený start jako důkaz, že každá environmentální proměnná zabrala.

KEEP_ALIVE je opačný případ a ty dva se nesmí házet do jednoho pytle. Ve stejné verzi byl také odstraněn, ale není tichý — rychlá kontrola kontejneru ukazuje, že do stdout loguje Environment variable of "KEEP_ALIVE" is deprecated and ignored. To je správné varování pro operátora. KEEP_ALIVE jsem nevedl stejným měřeným harnessen jako PREBOOT, takže to reportuji jako kontrolu, ne jako měření. Směr je ale jasný a důležitý: jen PREBOOT je tichá past. Browserless je k KEEP_ALIVE upřímnější, než by mu dávalo za pravdu obecné shrnutí „v2 ignoruje vaše v1 příznaky“.

Pro a proti

Pro

• Řízení přijetí, které se chová přesně tak, jak je zdokumentováno, a mění se s konfigurací — ověřeno při třech různých stropních hodnotách současně na stavových kódech klienta i ve vlastním účtování serveru.
• /pressure se ve třech krátkých bězích shodovalo s viditelnými počty running, queued a rejected; ber ho jako jeden z kandidátních vstupů pro autoscaling a alerting.
• Skutečný Chromium render bez klientského automatizačního kódu: jeden autentizovaný POST odhalil JS-injektovaný DOM, který statický fetch té samé stránky nevidí.
• V 30sekvenčním běhu nebylo pozorováno hromadění procesů Chrome; po skončení bylo 0 procesů Chrome a 0 zombie procesů.
• Jeden pokus s TIMEOUT vrátil 408 při 5,007 s proti rozpočtu 5,000 s; úklid a uvolnění slotu nebyly odděleně ověřeny.
• Autentizace je zapnutá od začátku: všechny čtyři REST endpointy bez tokenu vrací 401.
• Jeden docker run k připravené službě asi za 0,78 s a první render 0,32 s poté.

Proti

• Image 4,34 GB. To je poctivá hlavní cena a projeví se v registru, cache CI i v čase cold deploye.
• SSPL-1.0 nebo komerční licence Browserless. Posuď přesné aktuální podmínky podle svého modelu nasazení a distribuce.
• PREBOOT z v1 je na v2 přijat a tiše ignorován — žádná chyba, žádné varování, žádný klíč v /config.
• Provozuješ službu, ne jen přidáváš závislost: kontejner, token, síťovou cestu, strop přijetí a odpovědnost za upgrady.
• Požadavky ve frontě posouvaly end-to-end latenci zhruba na dvě délky relace v běhu (2, 2); samostatné čekání ve frontě nebylo měřeno.
• Naměřený REST timing zahrnuje HTTP hop a neizoluje cenu startu browseru ani neprokazuje znovupoužití browseru.

Kdo by to měl používat a kdo ne

Browserless dává smysl, když browser potřebuje víc než jedna věc. Renderovací služba sdílená mezi několika aplikacemi, tým, který chce screenshoty a PDF přes HTTP endpoint místo závislosti na Chromu v každé službě, job pipeline, která skutečně potřebuje kapacitní strop s měřitelným backpressure — to je přesně ten tvar, na který to sedí. Pokud už provozuješ Docker a někdo za deploy odpovídá, provozní příběh je jasný: předvídatelné přijetí, pozorovatelný backpressure a žádné hromadění procesů Chrome ani zombie procesů v 30relacním sekvenčním testu.

Je to také správná volba, pokud alternativou je, že každá služba ve stacku instaluje vlastní Chromium. Centralizovat to do jednoho kontejneru s tokenem a stropem je skutečně dobrý architektonický kompromis.

Vynech to, pokud píšeš jeden skript. Tahat 4,3 GB a spouštět kontejner jen proto, aby si jediný Python soubor stáhl vyrenderovanou stránku, je na malý úkol hodně ceremonie — browser knihovna v procesu to zvládne bez samostatného nasazení služby. Vynech to, pokud ti licenční podmínky SSPL nevyhovují pro komerční produkt a neumíš je vyřešit. Vynech to, pokud vlastně potřebuješ browser, který přijde předem zahřátý bez cold costu, protože PREBOOT ti to na v2 nedá. A vynech to, pokud je tvůj skutečný problém anti-bot handling, protože ten sedí v endpointu, který jsem záměrně netestoval a za který neručím.

Alternativy, včetně místa, kde dává smysl Thunderbit

Důležitější srovnání není Browserless proti jinému kontejneru. Je to o tom, kde browser běží a kdo je zodpovědný za jeho udržování při životě.

Související recenze: Browsertrix Crawler review.

Související recenze: chromedp review.

Pokud chceš browser ve vlastním procesu a nevadí ti psát waity, je knihovna lehčí a bez deploye služby. Tuhle část jsem rozebral v porovnání Playwright vs Puppeteer a ve širším přehledu open-source scraping projektů.

Pokud nechceš browser vůbec provozovat, naše vlastní Thunderbit je jedna z řízených alternativ. Browserless vrací vyrenderovaný obsah, který si tvůj kód interpretuje; Thunderbit může vrátit Markdown nebo datům odpovídající schema, zatímco infrastrukturu pro renderování spravuje poskytovatel. Tento článek neměřil latenci, kapacitu, chování při chybách, kvalitu extrakce ani cenu Thunderbit, takže tabulka popisuje hranice odpovědnosti, ne výkonové srovnání.

Související čtení z téže testovací série: Crawl4AI review pokrývá browser-backed Markdown pipeline, kterou provozuješ sám, a přehled web scraping nástrojů mapuje širší kategorii.

Vyzkoušet Thunderbit pro extrakci webových dat

Verdikt

Měl bys Browserless provozovat? Ano, pokud browserovou práci potřebuje víc volajících, někdo může kontejner spravovat a licenční posouzení schválí model nasazení. Ve třech syntetických bězích pro přijetí odpovídal počet přijatých požadavků CONCURRENT + QUEUED, přetečení dostalo 429 a /pressure sedělo s počty viditelnými pro klienta. V samostatné sekvenční kontrole na 30 relací se nehromadily žádné procesy Chrome ani zombie. Jeden timeout test vrátil 408 poblíž nastavené hranice. To jsou užitečná omezená pozorování, ne univerzální záruky.

Poctivě ale zvaž náklad. Je to image o velikosti 4,34 GB a služba, kterou provozuješ, ne závislost, kterou jen přidáš; tento test neprokázal rychlostní výhodu proti browser knihovně běžící v procesu. Získáváš browser, který můžeš dávkovat: známý strop a měřitelný backpressure. V 30sekvenční kontrole nebylo pozorováno hromadění procesů Chrome ani zombie procesů. Cenou je provozní váha a licence, kterou si musíš přečíst. Pokud renderuješ pár stránek z jednoho skriptu, tahle výměna se nevyplatí. Pokud ale provozuješ renderovací vrstvu, na které závisí více služeb, ano — jen si při cestě dovnitř zkontroluj v1 environment variables, protože PREBOOT tam bude sedět jako zaměstnaný a přitom nebude dělat vůbec nic.

Vyzkoušet Thunderbit pro extrakci webových dat Get Started Free

Často kladené otázky

Zrychluje Browserless headless Chrome? Tento test na to neumí odpovědět. HTTP endpoint se stal dostupným 0,78 s po docker run; první volání /content pak trvalo 0,32 s a pozdější volání ve stejném kontejneru zhruba 0,15 s. Tato čísla kombinují HTTP round trip, práci browseru, navigaci a přenos odpovědi. Harness neizoloval čas startu, nesledoval znovupoužití procesů a nezveřejnil srovnatelný in-process benchmark. Browserless používej jako sdílenou službu s řízením přijetí a pak si změř vlastní latenci.

Co se stane, když překročíš limit souběžnosti Browserless? Dostaneš okamžitě HTTP 429. Strop je přesně CONCURRENT + QUEUED a ověřil jsem to ve třech konfiguracích: (2,2) přijalo 4 a odmítlo 4, (3,5) přijalo 8 a odmítlo 4, (5,5) přijalo 10 a odmítlo 4. Endpoint /pressure na serveru pokaždé hlásil shodné počty running, queued a recentlyRejected. Důležité je, že požadavky ve frontě nepadnou, ale čekají — při (2,2) s pětisekundovou prací trvaly úspěšné odpovědi mezi 5,7 s a 11,0 s. V klientovi proto ber 429 jako backpressure s retry a backoffem.

Funguje PREBOOT v Browserless v2 ještě? Ne. PREBOOT byl v 2.0.0 odstraněn a v2 přijme -e PREBOOT=true bez chyby nebo varování, ale nic s ním neudělá. Neaktivitu jsem potvrdil třemi způsoby: latence byla nerozeznatelná od výchozího stavu, nečinný kontejner s PREBOOT=true měl 0 čekajících procesů chrome a /config vůbec neobsahuje klíč preboot. Pokud jsi migroval config z v1, instance nejsou předem zahřáté. Všimni si, že KEEP_ALIVE, odstraněný ve stejné verzi, naopak loguje varování „deprecated and ignored“ — problém tichého selhání je tedy specifický pro PREBOOT.

Je Browserless zdarma pro komerční použití? Repozitář nabízí SSPL-1.0 nebo komerční licenci Browserless, ale tento článek nemapuje konkrétní komerční nebo uzavřené scénáře na jednu či druhou volbu. Projdi aktuální LICENSE a oficiální návod k nasazení, pak nech osobu odpovědnou za licencování software posoudit tvůj model nasazení a distribuce.

Nezanechává Browserless zombie procesy Chrome? V testovaném krátkém okně se žádné nehromadily. Po 30 sekvenčních relacích měl kontejner 0 procesů Chrome a 0 zombie procesů, zůstaly jen dumb-init, node, Xvfb, start.sh a sh. Detektor během živé relace napočítal 11 procesů rodiny chrome, takže nebyl slepý. Paměť kontejneru vzrostla z 294 MiB na 303 MiB a pak se ve vzorcích ustálila. Nejde o mnohahodinový, konkurenční ani tisícerelacní endurance výsledek.