Chromium waży około 280 MB. Limit niespakowanej paczki w AWS Lambda to 250 MB. Jeśli kiedykolwiek próbowałeś zrobić npm install puppeteer i wdrożyć wszystko bezpośrednio do Lambda, wiesz już, jak ten rachunek się kończy — po prostu się nie zgadza.
Spędziłem wystarczająco dużo czasu na debugowaniu błędów „Failed to launch the browser process” o 2 w nocy, żeby wiedzieć, że ten temat zasługuje na porządne porównanie, a nie kolejny poradnik pokazujący tylko jedną metodę i zostawiający Cię z domysłami co do pozostałych dwóch. Dlatego właśnie ten tekst obejmuje: Layers vs. Container Images vs. bezpośredni upload ZIP, aktualną na 2026 macierz zgodności wersji oraz sekcję rozwiązywania problemów dla pięciu błędów, na które statystycznie najłatwiej się natknąć.
Czym jest Puppeteer na AWS Lambda i po co w ogóle tego używać
Puppeteer to biblioteka Node.js, która steruje bezgłowym Chromium przez Chrome DevTools Protocol. Lambda to bezserwerowe środowisko obliczeniowe AWS — płacisz za każde wywołanie, system skaluje się automatycznie i nie dotykasz serwera. Połączenie tych dwóch rzeczy daje konfigurację do automatyzacji przeglądarki, która może rozdzielać zadania na setki równoległych wykonań bez konieczności stawiania choćby jednej instancji EC2.
Zastosowania są zwykle bardzo podobne w różnych zespołach: web scraping, generowanie zrzutów ekranu i PDF-ów, monitoring syntetyczny, prerenderowanie aplikacji SPA pod SEO oraz automatyczne testy UI. Problem zawsze jest ten sam, o którym wspomniałem wyżej — rozmiar Chromium kontra limity paczki Lambda. Dlatego nikt nie wdraża pełnego puppeteer (który pobiera własną kopię Chromium) do Lambda. Zamiast tego używa się puppeteer-core (bez dołączonej przeglądarki) razem z binarką Chromium zoptymalizowaną pod Lambda, najczęściej @sparticuz/chromium.
Ta jedna zmiana — puppeteer-core zamiast puppeteer — rozwiązuje 80% problemu z rozmiarem jeszcze zanim napiszesz pierwszą linijkę konfiguracji wdrożenia.
Layers vs. Container Image vs. ZIP: najpierw wybierz ścieżkę
Jest coś, co mnie frustrowało podczas researchu: prawie każdy istniejący poradnik opisuje dokładnie jedną metodę wdrożenia. Tutoriale AWS SAM używają Layers. Przykłady CDK używają Dockera. Jakiś losowy wpis na Substacku pokazuje surowy ZIP z binarką Chromium hostowaną na S3. Nikt nie zestawia tych opcji obok siebie, więc pierwsza decyzja, którą naprawdę musisz podjąć — która metoda wdrożenia pasuje do mojej sytuacji — jest całkowicie pomijana.
Naprawmy to.
| Kryterium | Lambda Layers | Obraz kontenerowy (Docker) | Bezpośredni upload ZIP |
|---|---|---|---|
| Maksymalny rozmiar paczki | 250 MB niespakowane łącznie ze wszystkimi warstwami | obraz 10 GB | 250 MB niespakowane |
| Złożoność wdrożenia | Średnia (zarządzanie ARN warstwy) | Wyższa (Dockerfile + push do ECR) | Najniższa (zip i upload) |
| Wpływ na cold start | Umiarkowany | Nieco wyższy (większy obraz do pobrania) | Umiarkowany |
| Aktualizacja Chromium | Ponowne opublikowanie wersji warstwy | Przebudowanie obrazu | Ponowny upload ZIP-a |
| Najlepsze dla | Szybkich prototypów, użytkowników Serverless Framework | Obciążeń produkcyjnych, zespołów z Docker CI | Prostych, jednorazowych funkcji |
| Obsługa IaC | SAM, Serverless Framework | CDK, SAM, Terraform | Konsola, dowolne IaC |
Zarówno limit 250 MB, jak i 10 GB pochodzą wprost z dokumentacji limitów AWS Lambda — to nie jest liczba, która ostatnio bardzo się zmieniała, ale właśnie ten parametr z góry decyduje o całej strategii wdrożenia.
Moja praktyczna zasada: jeśli tworzysz prototyp albo i tak używasz Serverless Framework, zacznij od Layers. Jeśli wdrażasz produkcyjnie i zespół ma już Docker CI/CD, wybierz Container Image — limit 10 GB daje dużo swobody. Jeśli potrzebujesz tylko jednej funkcji do sporadycznego robienia screenów, bezpośredni ZIP to najmniej ceremonii.
Wszystkie trzy ścieżki bazują pod spodem na tym samym zestawie zależności: puppeteer-core + @sparticuz/chromium. Metoda wdrożenia zmienia tylko sposób pakowania, a nie to, co pakujesz.
Macierz zgodności wersji na 2026 rok (przestań zgadywać)
To jest część, która naprawdę potrafi kosztować ludzi miesiące, a nie godziny. Najgłośniejsza skarga na Stack Overflow i w issue na GitHubie zwykle nie brzmi „jak to wdrożyć”, tylko „dlaczego działające wdrożenie nagle przestało działać po aktualizacji npm”. Winowajcą niemal zawsze jest niezgodność między @sparticuz/chromium, puppeteer-core i runtime’em Node.js.
Najpierw ważna uwaga: chrome-aws-lambda (oryginalny pakiet alixaxel) jest przestarzały i wycofany. Nie działa poprawnie na Node 18+ i nie nadąża za kolejnymi wersjami Chromium. Jeśli trafisz na poradnik, który się na niego powołuje, zamknij kartę — czytasz nieaktualne informacje. Każdy aktualny przewodnik powinien odsyłać do @sparticuz/chromium.
Korzystaj z tej zasady zgodności zamiast sprawdzać numery wersji „na oko”:
| Komponent | Zasada wersjonowania | Co sprawdzić przed wdrożeniem |
|---|---|---|
puppeteer-core | Wybierz wersję Puppeteer potrzebną Twojej aplikacji | Sprawdź build Chromium obsługiwany przez tę wersję Puppeteer |
@sparticuz/chromium | Główna wersja śledzi główną wersję Chromium, a nie Puppeteer | Dopasuj do builda Chromium z tabeli wsparcia Puppeteer i przeczytaj release notes Sparticuz |
| AWS Lambda Node.js runtime | Użyj aktualnie wspieranego runtime’u Lambda | Uruchom test po każdym update runtime’u lub paczki |
| Architektura | Pakiet npm zawiera binarki x64; wsparcie arm64 zaczyna się od Chromium v135 przez warstwę arm64 lub remote pack | Dopasuj dokładnie architekturę Lambda, artefakt warstwy/paczki i wersję Chromium |
Celowo nie wpisuję tu sztywnej pary pakietów, bo @sparticuz/chromium podąża za cyklem wydawniczym Chromium i nie używa klasycznego semver w prosty sposób. Zacznij od oficjalnej strony Puppeteer Chromium Support, sprawdź główną wersję Chromium obsługiwaną przez wybraną wersję Puppeteer, a potem wybierz odpowiadającą jej główną wersję @sparticuz/chromium. Na końcu przeczytaj release notes Sparticuz, żeby sprawdzić zmiany łamiące zgodność na poziomie patcha i szczegóły architektury. Nie instaluj po prostu tych samych numerów głównych w obu paczkach, chyba że takie mapowanie zostało potwierdzone przez te dwa źródła.
Jak wdrożyć Puppeteer na AWS Lambda z użyciem Lambda Layers
Lambda Layer pozwala spakować Chromium osobno od kodu funkcji, dzięki czemu sam handler pozostaje niewielki i możesz używać tej samej warstwy Chromium w wielu funkcjach. To najbliższe „quick startowi” rozwiązanie w tym obszarze.
Krok 1: Zainstaluj puppeteer-core i pakiet -min
Gdy pliki Chromium znajdują się w Lambda Layer, trzymaj paczkę funkcji małą, używając @sparticuz/chromium-min. Podmień placeholdery na zgodne wersje, które potwierdziłeś powyżej:
npm install puppeteer-core@$PUPPETEER_VERSION \
@sparticuz/chromium-min@$CHROMIUM_VERSION
Instalujesz puppeteer-core — a nie puppeteer — bo nie pobiera automatycznie przeglądarki. Pakiet -min dostarcza helpery do uruchomienia, a warstwa dostarcza skompresowane Brotli pliki Chromium w /opt/chromium.
Krok 2: Utwórz lub podłącz warstwę Chromium Lambda Layer
Użyj archiwum warstwy dla konkretnej architektury dołączonego do oficjalnego release Sparticuz albo zbuduj archiwum z oficjalnego repozytorium. Dla Lambda x86_64 udokumentowana kompilacja wygląda tak:
git clone --depth=1 https://github.com/sparticuz/chromium.git
cd chromium
make chromium.x64.zip
Wynikiem będzie chromium.x64.zip. Wgraj go do S3 i opublikuj jako Lambda Layer z runtime’em i architekturą, których faktycznie używasz. Dla arm64 użyj odpowiadającego artefaktu arm64 lub celu budowania; nie podpinaj archiwum x64 do funkcji arm64.
Jeśli używasz SAM, podepnij ARN warstwy bezpośrednio w template.yaml:
Resources:
PuppeteerFunction:
Type: AWS::Serverless::Function
Properties:
Layers:
- arn:aws:lambda:us-east-1:XXXXXXXXXXXX:layer:chromium-layer:1
Krok 3: Napisz handler Lambda
Oto działający wzorzec handlera, który otwiera stronę i zwraca tytuł:
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();
}
};
Zwróć uwagę na blok finally. Zawsze zamykaj przeglądarkę właśnie tam — jeśli tego nie zrobisz, ciepłe środowiska Lambda będą kumulować martwe procesy przeglądarki między wywołaniami i w końcu trafisz na dziwne błędy pamięci, które nie mają nic wspólnego z samym kodem.
Krok 4: Ustaw pamięć, timeout i architekturę
Ustaw pamięć na co najmniej 1024 MB — do czegoś więcej niż banalny screenshot polecałbym 1536–2048 MB. Timeout ustaw na minimum 60 sekund. Zablokuj architekturę na x86_64, chyba że potwierdziłeś wsparcie arm64 dla dokładnie tej wersji Chromium, której używasz (to potrafi się różnić między wydaniami).
Krok 5: Wdróż i przetestuj
sam build && sam deploy --guided
Uruchom funkcję testowym eventem, a jeśli coś pójdzie nie tak, od razu sprawdź CloudWatch Logs — 90% błędów z sekcji troubleshooting poniżej będzie tam widocznych bardzo jasno.
Jak wdrożyć Puppeteer na AWS Lambda z użyciem Container Image (Docker)
Obrazy kontenerowe rozwiązują problem 250 MB, bo zamiast tego dostajesz limit 10 GB. To zazwyczaj lepszy wybór dla produkcji, zwłaszcza jeśli zespół i tak ma Dockera w pipeline CI.
Krok 1: Utwórz Dockerfile
Zacznij od oficjalnego AWS Lambda base image dla Node.js, zainstaluj zależności i ustaw handler:
FROM public.ecr.aws/lambda/nodejs:20
COPY package*.json ./
RUN npm install --production
COPY . .
CMD ["index.handler"]
W zależności od pakietu Chromium możesz potrzebować doinstalować kilka bibliotek współdzielonych przez yum install (więcej o tym w sekcji troubleshooting) — @sparticuz/chromium zawiera większość potrzebnych elementów, więc to rozwiązanie jest znacznie mniej uciążliwe niż ręczna instalacja pełnego Chrome.
Krok 2: Zbuduj obraz i wypchnij go 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
Trzymaj obraz w tym samym regionie co funkcja Lambda — pobieranie obrazu z innego regionu dodaje opóźnienie, którego nie potrzebujesz.
Krok 3: Utwórz funkcję Lambda z obrazu kontenerowego
Skieruj funkcję na URI obrazu ECR przez CLI lub CDK i ustaw pamięć (1536–2048 MB) oraz timeout (60–120 sekund) tak samo, jak zrobiłbyś to przy wdrożeniu oparte na Layers.
Krok 4: Wdróż i przetestuj
Uruchom testowy event i sprawdź wynik. Główna różnica względem Layers: nieco dłuższy cold start wynikający z większego obrazu do pobrania, ale zyskujesz dużo większy zapas na zależności.
Jak wdrożyć Puppeteer na AWS Lambda przez bezpośredni upload ZIP
To opcja bez fajerwerków — bez warstw do zarządzania, bez Dockera do budowania. Dobra do prototypów albo jednej funkcji, która nie musi skalować się w pełną platformę automatyzacji przeglądarki.
Krok 1: Zainstaluj zależności lokalnie
W przypadku samodzielnego ZIP-a użyj puppeteer-core + @sparticuz/chromium i przypnij obie wersje. Pełny pakiet zawiera skompresowane pliki Chromium i rozpakowuje je do /tmp w czasie działania. Używaj @sparticuz/chromium-min tylko wtedy, gdy te pliki są dostarczane osobno przez Lambda Layer albo szybki zdalny URL pakietu; pakiet -min sam nie zawiera plików Brotli.
Krok 2: Spakuj funkcję do ZIP-a
npm install --production
zip -r function.zip . -x "*.git*"
Flaga --production ma tu znaczenie — zależności developerskie zabierają miejsce z Twojego limitu 250 MB bez żadnego pożytku.
Krok 3: Wgraj i skonfiguruj funkcję Lambda
aws lambda update-function-code --function-name my-puppeteer-fn --zip-file fileb://function.zip
Jeśli ZIP przekracza 50 MB, nie wgrasz go bezpośrednio przez konsolę ani prostym poleceniem CLI — trzeba najpierw wrzucić go do S3 i podać URI S3. Pamięć, timeout i architekturę ustaw tak samo jak w dwóch poprzednich metodach.
Krok 4: Wdróż i przetestuj
Użyj tego samego przepływu: uruchomienie testu i sprawdzenie logów. Przy pełnym pakiecie chromium.executablePath() nie wymaga argumentu. Przy chromium-min podaj dokładny katalog warstwy albo URL remote pack, np. chromium.executablePath("/opt/chromium") dla układu warstwy opisanego powyżej. Zdalny pack dodaje pobieranie do pierwszego cold startu, więc hostuj go blisko funkcji i sprawdzaj wersję artefaktu oraz architekturę.
Argumenty puppeteer.launch(), które naprawdę działają na Lambda
To jest fragment, który wszyscy kopiują, więc zróbmy go poprawnie. Środowisko uruchomieniowe Lambda nie ma /dev/shm, nie daje dostępu do GPU i działa z ograniczonymi uprawnieniami — co oznacza, że domyślne puppeteer.launch(), które działa świetnie na laptopie, tutaj po prostu... nie zadziała.
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,
});
Tablica chromium.args z @sparticuz/chromium zawiera już flagi ważne dla środowiska bezserwerowego — --no-sandbox, --disable-gpu, --disable-dev-shm-usage i podobne. Właśnie po to używa się tego pakietu zamiast ręcznie układać własną listę flag: nadąża za wymaganiami Chromium, więc Ty nie musisz.
Troubleshooting: 5 błędów, na które wpada każdy developer
Żaden poradnik, który znalazłem, nie ma porządnej sekcji troubleshooting, co jest trochę zaskakujące, biorąc pod uwagę, że błędy są prawdopodobnie powodem, dla którego w ogóle czytasz ten artykuł.
„Failed to launch the browser process”
Przyczyna: brakujące biblioteki współdzielone (libnss3.so, libatk itd.) albo nieprawidłowy executablePath.
Naprawa: @sparticuz/chromium dostarcza większość wymaganych zależności, dlatego jest polecanym pakietem zamiast samodzielnego budowania binarki Chromium. W wdrożeniach Dockerowych, jeśli problem nadal występuje, doinstaluj brakujące biblioteki jawnie w Dockerfile.
„Unzipped size must be smaller than 262144000 bytes”
Przyczyna: zainstalowałeś pełny pakiet puppeteer, który zawiera własne pobranie Chromium (~400 MB).
Naprawa: przejdź na puppeteer-core + @sparticuz/chromium. Jeśli naprawdę potrzebujesz więcej miejsca, wybierz podejście Container Image i limit 10 GB.
„Browser disconnected” albo timeout na browser.newPage()
Przyczyna: zbyt mało pamięci Lambda albo brak flag takich jak --disable-gpu w argumentach uruchomieniowych.
Naprawa: ustaw pamięć na co najmniej 1024 MB (ja poszedłbym wyżej — patrz benchmarki niżej) i upewnij się, że przekazujesz chromium.args, a nie okrojoną listę zrobioną ręcznie.
Działający kod psuje się po aktualizacji runtime’u Lambda
Przyczyna: AWS okresowo aktualizuje bazowy runtime, co może zmieniać wersje bibliotek współdzielonych albo patch wersje Node.js spod Twoich nóg.
Naprawa: przypnij wersję @sparticuz/chromium jawnie, przypnij wersję runtime’u Node w konfiguracji funkcji i — to jest część, którą ludzie często pomijają — testuj ponownie po każdym ogłoszeniu aktualizacji runtime’u AWS, a nie dopiero wtedy, gdy coś się zepsuje.
„Protocol error: Connection closed” po około 30 sekundach
Przyczyna: timeout Lambda jest krótszy niż czas potrzebny stronie na pełne załadowanie i wyrenderowanie.
Naprawa: zwiększ timeout do 60–120 sekund, ustaw jawnie page.setDefaultNavigationTimeout(), a jeśli nie potrzebujesz czekać na absolutnie wszystkie żądania sieciowe, zamień waitUntil: 'networkidle0' na waitUntil: 'domcontentloaded'.
Utrzymanie produkcyjne: pamięć, cold starty i koszty
Większość poradników kończy się na „zwiększ pamięć” i tyle. To nie jest praktyczna rada — poniżej znajdziesz to, co faktycznie zmienia się, gdy skaluje się pamięć w górę.
Pamięć a wydajność
Lambda przydziela CPU proporcjonalnie do pamięci, i to jest detal, który ludzi najczęściej zaskakuje. Więcej pamięci to nie tylko „więcej RAM-u” — to też szybszy CPU, który bezpośrednio przyspiesza renderowanie Chromium. W praktyce zespoły testujące Puppeteer zwykle obserwują zauważalnie szybsze wykonanie przy przejściu z 512 MB do zakresu 1536–2048 MB, choć dokładne liczby będą mocno zależeć od stron, które renderujesz. Zamiast podawać konkretną tabelę benchmarków, która będzie już nieaktualna, gdy to przeczytasz, zrób własny test przy 512 MB, 1024 MB, 1536 MB i 2048 MB na rzeczywistych stronach docelowych — to dziesięć minut pracy, które pokażą Ci dokładnie, gdzie leży najlepszy punkt cena/wydajność.
Provisioned Concurrency dla cold startów
Jeśli robisz coś wrażliwego na opóźnienia — monitoring syntetyczny, API do zrzutów ekranu w czasie rzeczywistym — cold starty są wrogiem. Provisioned Concurrency utrzymuje określoną liczbę środowisk wykonawczych w stanie gotowości, eliminując koszt cold startu kosztem płacenia za tę bezczynną pojemność. To ma sens szczególnie wtedy, gdy opóźnienie jest ważniejsze niż czysta efektywność kosztowa.
arm64 (Graviton) dla oszczędności
Funkcje Lambda oparte na Graviton są około 20% tańsze niż odpowiedniki x86_64. Haczyk: wsparcie @sparticuz/chromium dla arm64 było historycznie bardziej ograniczone niż dla x86_64, więc przed przejściem na Graviton w produkcji upewnij się jawnie dla przypiętej wersji.
VPC vs. brak VPC
Umieszczenie funkcji w VPC kiedyś powodowało zauważalne opóźnienie cold startu; AWS przez ostatnie lata mocno zmniejszył tę różnicę, ale nie wyeliminował jej całkowicie. Wkładaj funkcję do VPC tylko wtedy, gdy naprawdę musi się łączyć z prywatnymi zasobami, takimi jak RDS czy ElastiCache — w przeciwnym razie pomiń ten krok.
Kiedy całkiem zejść z Lambda
Jeśli zadania przeglądarkowe regularnie przekraczają 15 minut, potrzebują ponad 10 GB pamięci albo wymagają utrzymywania stałych sesji przeglądarki między żądaniami, Lambda zaczyna walczyć przeciwko Tobie. ECS Fargate jest do tego stworzony — długotrwałe obciążenia, konfigurowalne zasoby, rozliczanie za sekundę. Lambda świetnie nadaje się do krótkich, gwałtownych i łatwo równoległych zadań przeglądarkowych; to zły wybór, gdy obciążenie zaczyna przypominać trwałą usługę.
Kiedy wdrażanie Puppeteer na Lambda to zły pomysł
Warto powiedzieć to uczciwie: spora część osób trafiających na poradniki „Puppeteer + Lambda” tak naprawdę próbuje rozwiązać problem ekstrakcji danych, a nie automatyzacji przeglądarki. Jeśli naprawdę potrzebujesz ustrukturyzowanych danych ze stron — list produktów, danych kontaktowych, treści stron — całe pakowanie Chromium, przypinanie wersji i zarządzanie warstwami to narzut, którego nie musisz brać na siebie.
Zostań przy Lambda + Puppeteer, jeśli potrzebujesz prawdziwej kontroli nad przeglądarką: niestandardowych interakcji z formularzami, pipeline’ów do screenów i PDF-ów, monitoringu syntetycznego albo testów opartych na przeglądarce, gdzie faktycznie programowo manipulujesz DOM.
Rozważ API do ekstrakcji, jeśli Twoim celem końcowym jest JSON ze strony, a nie sesja przeglądarki, którą sam sterujesz. Thunderbit Open API obsługuje renderowanie JS, mechanizmy antybotowe i CAPTCHA przez jedno wywołanie HTTP — POST /extract z JSON Schema daje ustrukturyzowane dane, a POST /distill zwraca czysty Markdown. Jest też serwer MCP (thunderbit_extract, thunderbit_distill) dla agentów AI, które muszą pobierać dane w trakcie workflow bez uruchamiania własnej przeglądarki.
| Czynnik | Lambda + Puppeteer (DIY) | API do ekstrakcji (np. Thunderbit) |
|---|---|---|
| Czas konfiguracji | Godziny (pakowanie, warstwy, debugowanie) | Minuty (klucz API + wywołanie HTTP) |
| Utrzymanie | Ciągłe (przypinanie wersji, aktualizacje runtime’u) | Obsługuje dostawca |
| Obsługa anty-botów | Ręczna (stealth plugins, proxy) | Wbudowana |
| Format wyjściowy | Surowy HTML/zrzuty, które sam parsujesz | Ustrukturyzowany JSON przez schemat |
| Najlepsze dla | Pełna automatyzacja przeglądarki, testy, własne flow | Ekstrakcja danych, scraping, ingest treści |
Powiem wprost: jeśli spędzasz godziny na debugowaniu binarek Chromium tylko po to, żeby wyciągnąć JSON z kart produktowych, to znak, że rozwiązujesz niewłaściwy problem. Zostaw ścieżkę DIY na Lambda na momenty, gdy naprawdę musisz sterować przeglądarką — do samej ekstrakcji jest lepsza, prostsza droga. Jeśli porównujesz te podejścia dla konkretnego projektu, nasz przewodnik po AI web scraperach omawia temat szerzej, a rozszerzenie Thunderbit do Chrome warto sprawdzić, jeśli chcesz przetestować podejście „najpierw ekstrakcja”, zanim wybierzesz jedną ze ścieżek.
Podsumowanie
Trzy metody wdrożenia, jeden powracający motyw: przypinaj wersje, daj Chromium wystarczająco dużo pamięci i dopasuj metodę wdrożenia do realnych ograniczeń, a nie do pierwszego poradnika, na który trafiłeś. Layers do szybkiej iteracji, Container Images do produkcji na większą skalę, ZIP do prostych jednorazowych przypadków. A jeśli tak naprawdę zajmujesz się ekstrakcją danych, a nie automatyzacją przeglądarki — może się okazać, że specjalistyczne API do ekstrakcji oszczędzi Ci całego problemu z pakowaniem.
FAQ
Czy można uruchomić Puppeteer na AWS Lambda w 2026?
Tak — używając puppeteer-core razem z @sparticuz/chromium, wdrożonych przez Layers, Container Image albo bezpośredni ZIP. Pełny pakiet puppeteer i przestarzały chrome-aws-lambda nie działają już niezawodnie na aktualnych runtime’ach Lambda.
Jaki jest maksymalny rozmiar paczki dla AWS Lambda?
250 MB niespakowane dla wdrożeń Layers i ZIP; 10 GB dla wdrożeń Container Image, zgodnie z limitami AWS Lambda.
Czy chrome-aws-lambda jest nadal utrzymywany?
Nie. Oryginalny pakiet chrome-aws-lambda (autorstwa alixaxel) jest przestarzały i psuje się na Node 18+. Zamiast niego używaj @sparticuz/chromium — to obecnie aktywnie utrzymywany standard.
Ile pamięci potrzebuje Puppeteer na AWS Lambda?
1024 MB to praktyczne minimum; 1536–2048 MB to poziom, przy którym wydajność zaczyna być naprawdę komfortowa. Poniżej 1024 MB wykonanie będzie wyraźnie wolniejsze, ponieważ Lambda wiąże przydział CPU z pamięcią.
Jak skrócić cold starty Puppeteer na Lambda?
Przydziel więcej pamięci (co da też więcej CPU), rozważ Provisioned Concurrency, jeśli opóźnienie jest krytyczne, i trzymaj paczkę wdrożeniową możliwie lekką — każda dodatkowa zależność oznacza dłuższy cold start.
