Chromium má zhruba 280 MB. Nezkomprimovaný limit balíčku pro AWS Lambda je 250 MB. Pokud jste někdy zkusili npm install puppeteer a nasadili to rovnou do Lambda, už víte, jak ta matematika dopadne (nedopadne).
Strávil jsem dost času laděním chyb typu „Failed to launch the browser process“ ve dvě ráno, abych věděl, že si tohle téma zaslouží pořádné porovnání, ne další návod, který ukáže jednu cestu a nechá vás hádat o dalších dvou. Přesně tohle tedy dostanete: Layers vs. Container Images vs. přímé ZIP nahrání, aktuální matici kompatibility verzí pro rok 2026 a sekci řešení problémů pro pět chyb, na které nejspíš narazíte jako první.
Co je Puppeteer na AWS Lambda a proč to vůbec řešit
Puppeteer je knihovna pro Node.js, která ovládá headless Chromium přes Chrome DevTools Protocol. Lambda je serverless výpočetní služba od AWS — platíte jen za spuštění, škáluje se automaticky a nemusíte spravovat žádný server. Když to spojíte dohromady, získáte serverless automatizace prohlížeče, která zvládne stovky paralelních běhů, aniž byste museli připravovat jedinou instanci EC2.
Použití bývá napříč týmy podobné: web scraping, generování screenshotů a PDF, syntetické monitorování, předrenderování single-page aplikací pro SEO a automatizované testování UI. Problém je pořád stejný jako výše — velikost Chromia versus limity Lambda pro balíčky. Proto nikdo nenasazuje plný balíček puppeteer (který si stahuje vlastní Chromium) přímo do Lambda. Místo toho se používá puppeteer-core (bez přibaleného prohlížeče) spolu s Chromium binárkou optimalizovanou pro Lambda, nejčastěji @sparticuz/chromium.
Tahleta jediná změna — puppeteer-core místo puppeteer — vyřeší 80 % problému s velikostí ještě dřív, než napíšete jediný řádek konfiguračního kódu pro nasazení.
Layers vs. Container Image vs. ZIP: Nejprve si vyberte cestu
Při rešerši mě zarazilo, že téměř každý existující návod popisuje jen jednu metodu nasazení. Tutoriály pro AWS SAM používají Layers. Příklady v CDK používají Docker. Nějaký náhodný post na Substacku zase ukazuje holý ZIP s Chromium binárkou hostovanou na S3. Nikdo je nedá vedle sebe, takže první skutečně důležité rozhodnutí — která metoda nasazení se hodí právě pro váš případ — se úplně přeskočí.
Tak to pojďme napravit.
| Kritérium | Lambda Layers | Container Image (Docker) | Přímé ZIP nahrání |
|---|---|---|---|
| Maximální velikost balíčku | 250 MB po rozbalení (všech vrstev dohromady) | 10 GB image | 250 MB po rozbalení |
| Složitost nasazení | Střední (správa ARN vrstvy) | Vyšší (Dockerfile + push do ECR) | Nejnižší (zip a nahrát) |
| Dopad na cold start | Střední | Mírně vyšší (větší image se musí stáhnout) | Střední |
| Workflow aktualizace Chromia | Znovu publikovat verzi vrstvy | Znovu sestavit image | Znovu nahrát zip |
| Nejvhodnější pro | Rychlé prototypy, uživatele Serverless Framework | Produkční workloady, týmy s Docker CI | Jednoduché jednorázové funkce |
| Podpora IaC | SAM, Serverless Framework | CDK, SAM, Terraform | Console, libovolné IaC |
Jak limit 250 MB, tak 10 GB pochází přímo z dokumentace kvót AWS Lambda — není to číslo, které by se často měnilo, ale je to omezení, které dopředu určí celou vaši strategii nasazení.
Moje jednoduché pravidlo: pokud jen prototypujete nebo už používáte Serverless Framework, začněte s Layers. Pokud míříte do produkce a váš tým už má Docker CI/CD, zvolte Container Image — limit 10 GB vám dá mnohem víc prostoru. Jestli potřebujete jen jednu funkci na občasné snímky obrazovky, přímé ZIP nahrání je nejméně administrativy.
Všechny tři cesty používají stejné základní dvojče závislostí: puppeteer-core + @sparticuz/chromium. Metoda nasazení mění způsob zabalení, ne to, co vlastně balíte.
Matice kompatibility verzí pro rok 2026 (přestaňte hádat)
Tohle je část, která lidem bere měsíce, ne hodiny. Nejhlasitější stížnost na Stack Overflow i v GitHub issues není „jak to mám nasadit“, ale „proč se moje funkční nasazení po update npm potichu rozbilo“. Viníkem bývá téměř vždy nesoulad mezi @sparticuz/chromium, puppeteer-core a runtime Node.js.
Nejdřív důležitá poznámka: chrome-aws-lambda (původní balíček od alixaxel) je zastaralý. Na Node 18+ nefunguje spolehlivě a nestíhá držet krok s vývojem Chromia. Pokud narazíte na návod, který na něj odkazuje, zavřete kartu — čtete něco neaktuálního. Každý současný návod by vás měl vést na @sparticuz/chromium.
Místo odhadování podle hlavních verzí balíčků použijte toto pravidlo kompatibility:
| Komponenta | Pravidlo pro verzi | Co ověřit před nasazením |
|---|---|---|
puppeteer-core | Zvolte verzi Puppeteer, kterou vaše aplikace potřebuje | Vyhledejte build Chromia, který daná verze Puppeteer podporuje |
@sparticuz/chromium | Hlavní verze sleduje hlavní verzi Chromia, ne hlavní verzi Puppeteer | Spárujte ji s buildem Chromia z tabulky podpory Puppeteer a přečtěte si release notes Sparticuz |
| AWS Lambda Node.js runtime | Použijte aktuálně podporovaný Lambda runtime | Po každé změně runtime nebo balíčků spusťte testovací invokaci |
| Architektura | npm balíček obsahuje x64 binárky; podpora arm64 začíná s Chromium v135 přes arm64 layer nebo remote pack | Přesně slaďte architekturu Lambda, artefakt layer/pack a verzi Chromia |
Záměrně tu neuvádím konkrétní dvojici balíčků natvrdo, protože @sparticuz/chromium se řídí vydáváním Chromia a nepoužívá běžné semver chování. Začněte na oficiální stránce Puppeteer Chromium Support, zjistěte hlavní verzi Chromia podporovanou vámi zvolenou verzí Puppeteer a pak vyberte odpovídající hlavní verzi @sparticuz/chromium. Nakonec si v release notes Sparticuz ověřte breaking changes na úrovni patchů i detaily architektury. Neinstalujte jen stejné číslo hlavní verze u obou balíčků, pokud to není výslovně potvrzené těmito dvěma zdroji.
Jak nasadit Puppeteer na AWS Lambda pomocí Lambda Layers
Lambda Layer umožňuje zabalit Chromium odděleně od kódu funkce, takže samotný handler zůstane malý a stejnou Chromium vrstvu můžete znovu použít napříč více funkcemi. Je to v tomhle prostoru nejbližší ekvivalent „rychlého startu“.
Krok 1: Nainstalujte puppeteer-core a balíček -min
Když jsou soubory Chromia uložené v Lambda Layeru, držte balíček funkce malý a použijte @sparticuz/chromium-min. Nahraďte zástupné verze kompatibilními verzemi, které jste si ověřili výše:
npm install puppeteer-core@$PUPPETEER_VERSION \
@sparticuz/chromium-min@$CHROMIUM_VERSION
Instalujete puppeteer-core — ne puppeteer — protože přeskočí automatické stahování prohlížeče. Balíček -min poskytuje pomocné funkce pro spuštění, zatímco layer dodá Brotli-komprimované soubory Chromia v /opt/chromium.
Krok 2: Vytvořte nebo připojte Chromium Lambda Layer
Použijte archiv vrstvy specifický pro architekturu, který je součástí oficiálního Sparticuz release, nebo archiv sestavte z oficiálního repozitáře. Pro x86_64 Lambda je dokumentovaný build tento:
git clone --depth=1 https://github.com/sparticuz/chromium.git
cd chromium
make chromium.x64.zip
Tím vznikne chromium.x64.zip. Nahrajte ho do S3 a publikujte jako Lambda Layer s runtime a architekturou, které skutečně používáte. Pro arm64 použijte odpovídající arm64 release artefakt nebo build target; nepřipojujte x64 archiv k funkci arm64.
Pokud používáte SAM, připojte ARN vrstvy přímo v template.yaml:
Resources:
PuppeteerFunction:
Type: AWS::Serverless::Function
Properties:
Layers:
- arn:aws:lambda:us-east-1:XXXXXXXXXXXX:layer:chromium-layer:1
Krok 3: Napište Lambda handler
Tady je funkční vzor handleru, který otevře URL a vrátí název stránky:
import puppeteer from "puppeteer-core";
import chromium from "@sparticuz/chromium-min";
export const handler = async () => {
const browser = await puppeteer.launch({
args: puppeteer.defaultArgs({ args: chromium.args, headless: "shell" }),
executablePath: await chromium.executablePath("/opt/chromium"),
headless: "shell",
});
try {
const page = await browser.newPage();
await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
return { title: await page.title() };
} finally {
await browser.close();
}
};
Všimněte si bloku finally. Prohlížeč tam vždy zavírejte — jinak se ve warm Lambda prostředích budou hromadit zombie procesy mezi jednotlivými invokacemi a nakonec narazíte na podivné paměťové chyby, které s vaším kódem vlastně nesouvisí.
Krok 4: Nastavte paměť, timeout a architekturu
Paměť nastavte minimálně na 1024 MB — pro cokoli víc než triviální screenshot bych doporučil 1536–2048 MB. Timeout nastavte alespoň na 60 sekund. Architekturu připněte na x86_64, pokud jste si výslovně nepotvrdili podporu arm64 pro vaši konkrétní verzi Chromia (to se mění release od release).
Krok 5: Nasazení a test
sam build && sam deploy --guided
Spusťte testovací event a hned zkontrolujte CloudWatch Logs, pokud se něco pokazí — 90 % chyb ze sekce řešení problémů níže se v těchto logách ukáže velmi jasně.
Jak nasadit Puppeteer na AWS Lambda pomocí Container Images (Docker)
Container images řeší problém s limitem 250 MB tím, že místo něj dostanete limit 10 GB. Pro produkční workloady je to většinou lepší volba, hlavně pokud už váš tým má Docker v CI pipeline.
Krok 1: Vytvořte Dockerfile
Začněte od oficiálního AWS Lambda base image pro Node.js, nainstalujte závislosti a nastavte handler:
FROM public.ecr.aws/lambda/nodejs:20
COPY package*.json ./
RUN npm install --production
COPY . .
CMD ["index.handler"]
Podle použitého balíčku Chromium můžete potřebovat nainstalovat i pár sdílených knihoven pomocí yum install (víc k tomu v sekci řešení problémů) — @sparticuz/chromium si většinu potřebných věcí balí s sebou, takže je to výrazně méně bolestivé než ruční instalace plného Chromu.
Krok 2: Sestavte image a pushněte ji do Amazon ECR
aws ecr create-repository --repository-name puppeteer-lambda
docker build -t puppeteer-lambda .
docker tag puppeteer-lambda:latest <account-id>.dkr.ecr.<region>.amazonaws.com/puppeteer-lambda:latest
aws ecr get-login-password | docker login --username AWS --password-stdin <account-id>.dkr.ecr.<region>.amazonaws.com
docker push <account-id>.dkr.ecr.<region>.amazonaws.com/puppeteer-lambda:latest
Image držte ve stejné oblasti jako Lambda funkci — pull z jiné regionu přidá latenci, kterou nepotřebujete.
Krok 3: Vytvořte Lambda funkci z container image
Funkci nasměrujte na URI image v ECR přes CLI nebo CDK a nastavte paměť (1536–2048 MB) a timeout (60–120 sekund) stejně jako u nasazení přes layer.
Krok 4: Nasazení a test
Spusťte testovací event a ověřte výstup. Hlavní kompromis oproti Layers: o něco vyšší cold start kvůli většímu pullu image, ale získáte mnohem větší prostor pro závislosti.
Jak nasadit Puppeteer na AWS Lambda pomocí přímého ZIP nahrání
Tohle je varianta bez zbytečností — žádné layers, žádný Docker. Hodí se pro prototypy nebo jednu samostatnou funkci, která se nemusí škálovat do celé platformy pro automatizaci prohlížeče.
Krok 1: Nainstalujte závislosti lokálně
Pro samostatný ZIP použijte puppeteer-core + @sparticuz/chromium a pevně připněte obě verze. Plný balíček obsahuje zkomprimované soubory Chromia a při běhu je rozbalí do /tmp. @sparticuz/chromium-min použijte jen tehdy, když jsou tyto soubory dodané zvlášť přes Lambda Layer nebo přes rychlou vzdálenou URL balíčku; balíček -min sám o sobě Brotli soubory neobsahuje.
Krok 2: Zabalte funkci a vytvořte ZIP
npm install --production
zip -r function.zip . -x "*.git*"
Přepínač --production je tady důležitý — vývojové závislosti vám zbytečně ukusují z limitu 250 MB.
Krok 3: Nahrajte a nakonfigurujte Lambda funkci
aws lambda update-function-code --function-name my-puppeteer-fn --zip-file fileb://function.zip
Pokud má váš ZIP víc než 50 MB, nemůžete ho nahrát přímo přes konzoli ani jednoduchým CLI příkazem — budete ho muset nejdřív nahrát do S3 a odkazovat na S3 URI. Paměť, timeout i architekturu nastavte stejně jako u předchozích dvou metod.
Krok 4: Nasazení a test
Použijte stejný postup „spustit a zkontrolovat logy“. U plného balíčku chromium.executablePath() nepotřebuje žádný argument. U chromium-min předejte přesnou cestu k layeru nebo URL vzdáleného balíčku, například chromium.executablePath("/opt/chromium") pro výše uvedené rozložení vrstvy. Vzdálený pack přidává stahování do prvního cold startu, takže ho hostujte co nejblíž funkci a ověřte verzi artefaktu i architekturu.
Argumenty pro puppeteer.launch(), které na Lambda skutečně fungují
Tohle je ukázka, kterou všichni kopírují, tak si ji pojďme nastavit správně. Výpočetní prostředí Lambda nemá /dev/shm, neposkytuje přístup ke GPU a běží s omezenými oprávněními — takže výchozí volání puppeteer.launch(), které funguje na notebooku, tady prostě... fungovat nebude.
const viewport = {
width: 1920,
height: 1080,
deviceScaleFactor: 1,
isMobile: false,
hasTouch: false,
isLandscape: true,
};
const browser = await puppeteer.launch({
args: await puppeteer.defaultArgs({ args: chromium.args, headless: "shell" }),
executablePath: await chromium.executablePath(),
headless: "shell",
defaultViewport: viewport,
});
Pole chromium.args z @sparticuz/chromium už obsahuje flagy důležité pro serverless prostředí — --no-sandbox, --disable-gpu, --disable-dev-shm-usage a podobně. Přesně proto má smysl tenhle balíček používat místo ručního skládání vlastního seznamu parametrů: sleduje požadavky Chromia za vás.
Řešení problémů: 5 chyb, na které narazí skoro každý vývojář
V žádném z návodů, které jsem našel, nebyla pořádná sekce řešení problémů, což je trochu zvláštní, když si uvědomíte, že právě chyby jsou dost pravděpodobně důvod, proč tenhle článek vůbec čtete.
„Failed to launch the browser process“
Příčina: chybějící sdílené knihovny (libnss3.so, libatk atd.) nebo špatně nastavený executablePath.
Řešení: @sparticuz/chromium balí většinu potřebných závislostí, proto je doporučovanou volbou oproti vlastnímu Chromium binárku. U Docker nasazení, pokud problém přetrvává, doplňte chybějící knihovny explicitně v Dockerfile přes yum install.
„Unzipped size must be smaller than 262144000 bytes“
Příčina: nainstalovali jste plný balíček puppeteer, který si přibalí vlastní Chromium download (~400 MB).
Řešení: přejděte na puppeteer-core + @sparticuz/chromium. Pokud opravdu potřebujete víc místa, přesuňte se na přístup s Container Image a jeho limitem 10 GB.
„Browser disconnected“ nebo timeout na browser.newPage()
Příčina: nedostatek paměti Lambda, nebo vám v launch args chybí flagy jako --disable-gpu.
Řešení: nastavte paměť aspoň na 1024 MB (já bych šel ještě výš — viz benchmarky níže) a ujistěte se, že posíláte chromium.args, ne zkrácený vlastní seznam.
Funkční kód se rozbije po aktualizaci Lambda runtime
Příčina: AWS průběžně patchuje runtime, což může změnit verze sdílených knihoven nebo patch verze Node.js pod vašima rukama.
Řešení: explicitně připněte verzi @sparticuz/chromium, připněte verzi Node runtime v konfiguraci funkce a — a to lidé často přeskočí — testujte znovu po každém oznámení změny runtime od AWS, ne až ve chvíli, kdy se něco rozbije.
„Protocol error: Connection closed“ po zhruba 30 sekundách
Příčina: timeout Lambda je kratší než doba, za kterou se stránka skutečně načte a vykreslí.
Řešení: zvyšte timeout na 60–120 sekund, nastavte page.setDefaultNavigationTimeout() explicitně a pokud nepotřebujete čekat na úplné doznívání všech síťových požadavků, změňte waitUntil: 'networkidle0' na waitUntil: 'domcontentloaded'.
Produkční zpevnění: paměť, cold starty a cena
Většina návodů říká jen „zvyšte paměť“ a tím to končí. To není moc užitečná rada — tady je, co se ve skutečnosti mění s rostoucí pamětí.
Paměť vs. výkon
Lambda alokuje CPU úměrně paměti, a právě to lidi často mate. Víc paměti neznamená jen „víc RAM“ — znamená to i rychlejší CPU, které přímo zrychluje renderování Chromia. V praxi týmy, které měří Puppeteer benchmarky, hlásí citelně rychlejší běh při přechodu z 512 MB do pásma 1536–2048 MB, i když přesná čísla budou hodně záviset na stránkách, které renderujete. Místo citování konkrétní benchmark tabulky, která bude za chvíli zastaralá, si udělejte vlastní test na 512 MB, 1024 MB, 1536 MB a 2048 MB proti skutečným cílovým stránkám — je to desetiminutový experiment, který vám přesně ukáže ideální poměr ceny a výkonu.
Provisioned Concurrency pro cold starty
Pokud běžíte něco citlivého na latenci — syntetické monitorování, API pro screenshoty v reálném čase — cold starty jsou váš nepřítel. Provisioned Concurrency drží určitý počet execution environmentů zahřáté a připravené, čímž odstraní penalizaci cold startu za cenu placení za nevyužitou kapacitu. Vyplatí se hlavně tam, kde je důležitější latence než maximální cenová efektivita.
arm64 (Graviton) pro úsporu nákladů
Lambda funkce na bázi Gravitonu jsou zhruba o 20 % levnější než ekvivalent na x86_64. Háček: podpora arm64 v @sparticuz/chromium byla historicky omezenější než u x86_64, takže si ji před přechodem na Graviton v produkci ověřte konkrétně pro svou připnutou verzi.
VPC vs. bez VPC
Umístění funkce do VPC dřív přidávalo výraznou latenci cold startu; AWS ten rozdíl v posledních letech výrazně zmenšilo, ale pořád není nulový. Funkci dávejte do VPC jen tehdy, když opravdu potřebuje přístup k privátním zdrojům jako RDS nebo ElastiCache — jinak ji tam nedávejte.
Kdy přestat používat Lambda úplně
Pokud vaše browser úlohy pravidelně přesahují 15 minut, potřebují víc než 10 GB paměti nebo vyžadují trvalé prohlížečové relace mezi requesty, Lambda vám v tu chvíli začne překážet. ECS Fargate je pro tohle stavěné — dlouho běžící compute s nastavitelnými zdroji a účtováním po sekundách. Lambda je skvělá pro krátké, nárazové a paralelizovatelné browser úlohy; jakmile se workload začne podobat perzistentní službě, je to špatný nástroj.
Kdy je nasazení Puppeteer na Lambda špatná volba
Stojí za to říct to na rovinu: velká část vývojářů, kteří skončí u návodů typu „Puppeteer + Lambda“, ve skutečnosti neřeší automatizaci prohlížeče, ale extrakci dat. Pokud potřebujete ze stránek jen strukturovaná data — produktové nabídky, kontaktní informace, obsah stránek — je všechen ten balast kolem Chromia, připínání verzí a správy layerů jen zbytečná režie.
Zůstaňte u Lambda + Puppeteer, pokud opravdu potřebujete ovládat prohlížeč: vlastní interakce s formuláři, pipeline pro screenshoty/PDF, syntetické monitorování nebo testování v prohlížeči, kde skutečně programově manipulujete s DOMem.
Zvažte scraping API, pokud je váš cíl strukturované JSON z webové stránky, ne vlastní browser session, kterou řídíte sami. Thunderbit Open API řeší renderování JS, anti-bot opatření i CAPTCHA přes jediný HTTP request — POST /extract s JSON Schema vám vrátí strukturovaná data, POST /distill zase čistý Markdown. K dispozici je také MCP server (thunderbit_extract, thunderbit_distill), pokud stavíte AI agenta, který potřebuje vytáhnout data uprostřed workflow bez vlastního prohlížeče.
| Faktor | Lambda + Puppeteer (DIY) | API pro extrakci (např. Thunderbit) |
|---|---|---|
| Čas na nastavení | Hodiny (balení, layers, ladění) | Minuty (API klíč + HTTP call) |
| Údržba | Průběžná (připínání verzí, aktualizace runtime) | Řeší poskytovatel |
| Řešení anti-bot ochrany | Ruční (stealth pluginy, proxy) | Vestavěné |
| Formát výstupu | Surové HTML / screenshoty, které si sami parsujete | Strukturované JSON podle schématu |
| Nejlepší pro | Plná automatizace prohlížeče, testování, vlastní flow | Extrakce dat, scraping, ingest obsahu |
Řeknu to napřímo: pokud trávíte hodiny laděním Chromium binárek jen proto, abyste z produktových stránek vytáhli JSON, je to signál, že řešíte špatný problém. DIY Lambda cestu si nechte pro situace, kdy opravdu potřebujete řídit prohlížeč — pro extrakci existuje přímější cesta. Pokud zvažujete tenhle kompromis pro konkrétní projekt, náš průvodce AI web scrapery rozebírá celý prostor podrobněji a rozšíření Thunderbit pro Chrome stojí za vyzkoušení, pokud si chcete nejdřív otestovat přístup „nejdřív extrakce“ předtím, než se rozhodnete pro jednu z cest.
Shrnutí
Tři metody nasazení, jedno společné pravidlo: připínejte verze, dejte Chromiu dost paměti, aby mělo z čeho žít, a vyberte metodu nasazení podle reálných omezení, ne podle prvního tutoriálu, na který jste narazili. Layers pro rychlé iterace, Container Images pro produkční škálování, ZIP pro jednoduché jednorázové použití. A pokud ve skutečnosti jen extrahujete data, neřídíte prohlížeč, možná zjistíte, že specializované API pro extrakci vám ušetří celý ten balík problémů s packagingem.
Často kladené otázky
Lze v roce 2026 spustit Puppeteer na AWS Lambda?
Ano — pomocí puppeteer-core v kombinaci s @sparticuz/chromium, nasazené přes Layers, Container Image nebo přímý ZIP. Plný balíček puppeteer a zastaralý chrome-aws-lambda už na současných runtimech Lambda nefungují spolehlivě.
Jaká je maximální velikost balíčku pro AWS Lambda? 250 MB po rozbalení pro Layers a ZIP nasazení; 10 GB pro Container Image nasazení, podle Lambda kvót AWS.
Je chrome-aws-lambda stále udržovaný?
Ne. Původní balíček chrome-aws-lambda od alixaxel je zastaralý a na Node 18+ padá. Použijte místo něj @sparticuz/chromium — v tuto chvíli jde o aktivně udržovaný standard.
Kolik paměti potřebuje Puppeteer na AWS Lambda? 1024 MB je praktické minimum; 1536–2048 MB je rozsah, kde se výkon začíná cítit pohodlně. Pod 1024 MB počítejte s výrazně pomalejším během, protože Lambda váže přidělení CPU na paměť.
Jak zkrátit cold starty Puppeteer na Lambda? Přidělte víc paměti (což zároveň znamená víc CPU), zvažte Provisioned Concurrency, pokud je latence pro váš use case kritická, a držte nasazovací balíček co nejlehčí — každá další závislost znamená delší cold start.
