Chromium weegt ongeveer 280 MB. De limiet voor een ongecomprimeerd AWS Lambda-pakket is 250 MB. Als je ooit npm install puppeteer hebt gedaan en daarna meteen naar Lambda hebt gedeployed, weet je al hoe die rekensom uitpakt: dat gaat gewoon niet passen.
Ik heb genoeg tijd verloren aan het debuggen van “Failed to launch the browser process”-fouten om te weten dat dit onderwerp een degelijke vergelijking verdient, en niet nog een tutorial die maar één aanpak laat zien en je laat gokken naar de andere twee. Dus precies dat krijg je hier: Layers versus container images versus directe ZIP-upload, een compatibiliteitsmatrix die ook in 2026 nog klopt, en een troubleshooting-sectie met de vijf fouten waar je statistisch gezien het vaakst tegenaan loopt.
Wat is Puppeteer op AWS Lambda (en waarom zou je het gebruiken)
Puppeteer is een Node.js-bibliotheek die headless Chromium aanstuurt via het Chrome DevTools Protocol. Lambda is AWS’ serverless compute: je betaalt per uitvoering, het schaalt automatisch mee en je hoeft nooit zelf een server te beheren. Combineer die twee en je krijgt browserautomatisering die kan opschalen naar honderden parallelle runs, zonder dat je ook maar één EC2-instantie hoeft te provisionen.
De gebruiksscenario’s zijn voor teams meestal hetzelfde: webscraping, screenshots en PDF’s genereren, synthetische monitoring, single-page apps vooraf renderen voor SEO en geautomatiseerde UI-tests. Het probleem is steeds hetzelfde als hierboven: de grootte van Chromium versus de pakketlimieten van Lambda. Daarom deployt niemand de volledige puppeteer-package — die namelijk zijn eigen Chromium-download meeneemt — rechtstreeks naar Lambda. In plaats daarvan gebruik je puppeteer-core (zonder ingebouwde browser) in combinatie met een Lambda-geoptimaliseerde Chromium-binary, meestal @sparticuz/chromium.
Die ene stap — puppeteer-core in plaats van puppeteer — lost al 80% van het pakketgrootteprobleem op nog voordat je ook maar één regel deployconfiguratie hebt geschreven.
Layers versus container image versus ZIP: kies eerst je route
Tijdens mijn onderzoek viel me iets op: bijna elke bestaande gids behandelt precies één deploymethode. De AWS SAM-tutorials gebruiken Layers. De CDK-voorbeelden gebruiken Docker. Een willekeurige Substack-post gebruikt een ruwe ZIP met een Chromium-binary op S3. Niemand zet die opties naast elkaar, waardoor de eerste keuze die je eigenlijk moet maken — welke deploymethode past bij mijn situatie — volledig wordt overgeslagen.
Laten we dat dus rechtzetten.
| Criteria | Lambda Layers | Container Image (Docker) | Directe ZIP-upload |
|---|---|---|---|
| Maximale pakketgrootte | 250 MB ongecomprimeerd (over alle layers samen) | 10 GB image | 250 MB ongecomprimeerd |
| Deploycomplexiteit | Gemiddeld (beheer van layer ARN’s) | Hoger (Dockerfile + push naar ECR) | Laagst (zippen en uploaden) |
| Impact op cold starts | Gemiddeld | Iets hoger (grotere image pull) | Gemiddeld |
| Workflow voor Chromium-updates | Layer opnieuw publiceren | Image opnieuw builden | ZIP opnieuw uploaden |
| Beste voor | Snelle prototypes, gebruikers van Serverless Framework | Productieworkloads, teams met Docker-CI | Simpele eenmalige functies |
| IaC-ondersteuning | SAM, Serverless Framework | CDK, SAM, Terraform | Console, elke IaC |
Zowel de limiet van 250 MB als die van 10 GB komt rechtstreeks uit de AWS Lambda quota-documentatie. Dat is geen getal dat de laatste jaren veel is veranderd, maar het is wél de beperking die vooraf je hele deploystrategie bepaalt.
Mijn vuistregel, voor wat die waard is: als je aan het prototypen bent of al met Serverless Framework werkt, begin dan met Layers. Als je richting productie gaat en je team al Docker CI/CD heeft, kies dan voor Container Image — die grens van 10 GB geeft je veel meer ruimte. Als je gewoon af en toe één functie nodig hebt om screenshots te maken, is een directe ZIP de minste omweg.
Alle drie routes gebruiken onder water dezelfde basiscombinatie: puppeteer-core + @sparticuz/chromium. De deploymethode bepaalt alleen hoe je die combinatie verpakt, niet wat je verpakt.
De compatibiliteitsmatrix voor 2026 (stop met gokken)
Dit is het onderdeel waar mensen niet uren, maar maanden aan verliezen. De luidste klacht op Stack Overflow en in GitHub-issues is niet “hoe deploy ik dit”, maar “waarom brak mijn werkende deployment ineens stilletjes na een npm-update?” De boosdoener is bijna altijd een mismatch tussen @sparticuz/chromium, puppeteer-core en de Node.js-runtime.
Eerst de belangrijkste waarschuwing: chrome-aws-lambda (de originele alixaxel-package) is deprecated. Die werkt niet goed op Node 18+ en loopt achter op Chromium-releases. Kom je een tutorial tegen die die package nog gebruikt? Sluit die tab — je leest verouderde informatie. Elke actuele gids moet je doorverwijzen naar @sparticuz/chromium.
Gebruik deze compatibiliteitsregel in plaats van op gevoel versies bij elkaar te zoeken:
| Component | Versieregel | Wat je vóór deployment moet controleren |
|---|---|---|
puppeteer-core | Kies de Puppeteer-versie die je applicatie nodig heeft | Zoek op welke Chromium-build door die Puppeteer-release wordt ondersteund |
@sparticuz/chromium | De majorversie volgt de Chromium-major, niet de Puppeteer-major | Laat hem aansluiten op de Chromium-build uit de supporttabel van Puppeteer en lees de release notes van Sparticuz |
| AWS Lambda Node.js-runtime | Gebruik een momenteel ondersteunde Lambda-runtime | Draai na elke runtime- of package-update een testinvocatie |
| Architectuur | De npm-package bevat x64-binaries; arm64-ondersteuning start bij Chromium v135 via een arm64-layer of remote pack | Laat Lambda-architectuur, layer/pack-artifact en Chromium-versie exact overeenkomen |
Ik zet hier bewust geen vaste package-combinatie neer, omdat @sparticuz/chromium de releasecyclus van Chromium volgt en niet netjes in de gebruikelijke semantische versie-indeling past. Begin met de officiële Puppeteer Chromium Support-pagina, noteer de Chromium-major die jouw gekozen Puppeteer-release ondersteunt, en kies daarna dezelfde major van @sparticuz/chromium. Lees vervolgens de release notes van Sparticuz voor patch-level breaking changes en architectuurdetails. Installeer niet zomaar hetzelfde major-getal voor beide packages, tenzij die koppeling expliciet door die twee bronnen wordt bevestigd.
Puppeteer op AWS Lambda deployen met Lambda Layers
Met een Lambda Layer scheid je Chromium van je functencode, waardoor je handler klein blijft en je dezelfde Chromium-layer op meerdere functies kunt hergebruiken. Dit is in deze hele wereld het dichtst bij een echte “quick start”.
Stap 1: Installeer puppeteer-core en het -min-pakket
Wanneer de Chromium-bestanden in een Lambda Layer staan, houd je je functiepakket klein door @sparticuz/chromium-min te gebruiken. Vervang de placeholders door de compatibele versies die je hierboven hebt bevestigd:
npm install puppeteer-core@$PUPPETEER_VERSION \
@sparticuz/chromium-min@$CHROMIUM_VERSION
Je installeert puppeteer-core — niet puppeteer — omdat daarmee de automatische browserdownload wordt overgeslagen. Het -min-pakket levert de launch-hulpfuncties, terwijl de layer de Brotli-gecomprimeerde Chromium-bestanden onder /opt/chromium aanlevert.
Stap 2: Maak of verwijs naar een Chromium Lambda Layer
Gebruik het architecture-specifieke layer-archief dat hoort bij een officiële Sparticuz-release, of bouw het archief vanuit de officiële repository. Voor x86_64 Lambda is de gedocumenteerde build:
git clone --depth=1 https://github.com/sparticuz/chromium.git
cd chromium
make chromium.x64.zip
Dat levert chromium.x64.zip op. Upload die naar S3 en publiceer hem als een Lambda Layer met de runtime en architectuur die je echt gebruikt. Gebruik voor arm64 het bijbehorende arm64-release-artifact of build-target; koppel nooit een x64-archief aan een arm64-functie.
Gebruik je SAM, dan voeg je de layer-ARN direct toe in je template.yaml:
Resources:
PuppeteerFunction:
Type: AWS::Serverless::Function
Properties:
Layers:
- arn:aws:lambda:us-east-1:XXXXXXXXXXXX:layer:chromium-layer:1
Stap 3: Schrijf de Lambda-handler
Hier is een werkend handlerpatroon dat naar een URL navigeert en de paginatitel teruggeeft:
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();
}
};
Let op de finally-block. Sluit de browser daar altijd af — doe je dat niet, dan stapelen warme Lambda-omgevingen zombie browserprocessen op tussen invocations, en krijg je uiteindelijk vreemde geheugengerelateerde fouten die niets met je eigen code te maken hebben.
Stap 4: Configureer geheugen, timeout en architectuur
Zet het geheugen op minimaal 1024 MB — voor alles wat meer is dan een triviale screenshottaak zou ik 1536–2048 MB aanraden. Stel de timeout in op minstens 60 seconden. Pin je architectuur op x86_64, tenzij je voor jouw exacte Chromium-versie expliciet arm64-ondersteuning hebt bevestigd (dat verschilt per release).
Stap 5: Deploy en test
sam build && sam deploy --guided
Roep de functie aan met een testevent en kijk meteen in CloudWatch Logs als er iets misgaat — 90% van de fouten uit de troubleshooting-sectie hieronder zie je daar direct terug.
Puppeteer op AWS Lambda deployen met container images (Docker)
Container images lossen de 250MB-hoofdpijn helemaal op door je een grens van 10 GB te geven. Dit is meestal de betere keuze voor productieworkloads, vooral als je team Docker al in de CI-pijplijn heeft zitten.
Stap 1: Maak het Dockerfile
Begin met een officiële AWS Lambda base image voor Node.js, installeer je dependencies en stel de handler in:
FROM public.ecr.aws/lambda/nodejs:20
COPY package*.json ./
RUN npm install --production
COPY . .
CMD ["index.handler"]
Afhankelijk van je Chromium-package moet je misschien een paar shared libraries via yum install toevoegen (daarover meer in de troubleshooting-sectie). @sparticuz/chromium levert al het meeste mee dat nodig is, waardoor dit een stuk minder gedoe is dan Chrome volledig handmatig installeren.
Stap 2: Build en push naar 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
Houd de image in dezelfde regio als je Lambda-functie — cross-region image pulls voegen latency toe die je niet nodig hebt.
Stap 3: Maak de Lambda-functie op basis van de container image
Laat je functie via CLI of CDK verwijzen naar de ECR image-URI, en stel geheugen (1536–2048 MB) en timeout (60–120 seconden) in zoals je dat ook bij een layer-based deployment zou doen.
Stap 4: Deploy en test
Roep de functie aan met een testevent en controleer de output. Het belangrijkste verschil met Layers: iets langere cold starts door de grotere image pull, maar wel veel meer ruimte voor dependencies.
Puppeteer op AWS Lambda deployen met een directe ZIP-upload
Dit is de no-nonsense optie: geen layers om te beheren, geen Docker om te bouwen. Handig voor prototypes of een enkele functie die niet hoeft uit te groeien tot een heel browserautomatiseringsplatform.
Stap 1: Installeer de dependencies lokaal
Voor een zelfstandige ZIP gebruik je puppeteer-core + @sparticuz/chromium en pin je beide versies. De volledige package bevat de gecomprimeerde Chromium-bestanden en pakt die tijdens runtime uit naar /tmp. Gebruik @sparticuz/chromium-min alleen wanneer die bestanden apart worden aangeleverd via een Lambda Layer of een snelle remote-pack-URL; het -min-pakket bevat die Brotli-bestanden zelf niet.
Stap 2: Bundel en zip de functie
npm install --production
zip -r function.zip . -x "*.git*"
De --production-vlag is hier belangrijk — development dependencies vreten anders zonder reden aan je 250MB-budget.
Stap 3: Upload en configureer de Lambda-functie
aws lambda update-function-code --function-name my-puppeteer-fn --zip-file fileb://function.zip
Als je ZIP groter is dan 50 MB, kun je hem niet rechtstreeks via de console of een simpele CLI-call uploaden — dan moet je hem eerst naar S3 uploaden en daarna naar die S3-URI verwijzen. Stel geheugen, timeout en architectuur op dezelfde manier in als bij de vorige twee methodes.
Stap 4: Deploy en test
Gebruik dezelfde flow van aanroepen en logs controleren. Met het volledige pakket heeft chromium.executablePath() geen argument nodig. Met chromium-min geef je het exacte layer-pad of de remote-pack-URL op, bijvoorbeeld chromium.executablePath("/opt/chromium") voor de layer-opzet hierboven. Een remote pack voegt downloadwerk toe aan de eerste cold start, dus host hem zo dicht mogelijk bij de functie en controleer zowel de artifactversie als de architectuur.
De puppeteer.launch()-args die echt werken op Lambda
Dit is het snippet dat iedereen copy-past, dus laten we het meteen goed doen. De execution environment van Lambda heeft geen /dev/shm, geeft je geen GPU-toegang en draait met beperkte rechten — waardoor de standaard puppeteer.launch()-call die op je laptop prima werkt hier gewoon niet werkt.
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,
});
De chromium.args-array van @sparticuz/chromium bevat al de flags die belangrijk zijn voor een serverloze omgeving — --no-sandbox, --disable-gpu, --disable-dev-shm-usage en vergelijkbare opties. Dáár zit precies de meerwaarde van dit package boven een handmatig samengestelde lijst: het volgt de vereisten van Chromium, zodat jij dat niet hoeft te doen.
Troubleshooting: 5 fouten waar elke developer tegenaan loopt
Geen enkele gids die ik vond bevat een degelijke troubleshooting-sectie, terwijl fouten waarschijnlijk precies de reden zijn dat je dit artikel leest.
"Failed to launch the browser process"
Oorzaak: ontbrekende shared libraries (libnss3.so, libatk, enz.) of een onjuiste executablePath.
Oplossing: @sparticuz/chromium bundelt de meeste vereiste dependencies, en daarom is het de aanbevolen package boven zelf een Chromium-binary samenstellen. Krijg je dit in Docker nog steeds? Installeer dan de ontbrekende libraries expliciet met yum install in je Dockerfile.
"Unzipped size must be smaller than 262144000 bytes"
Oorzaak: je hebt de volledige puppeteer-package geĂŻnstalleerd, die zijn eigen Chromium-download meeneemt (~400MB).
Oplossing: stap over op puppeteer-core + @sparticuz/chromium. Heb je echt meer ruimte nodig, kies dan voor de Container Image-aanpak met de 10GB-grens.
"Browser disconnected" of timeout bij browser.newPage()
Oorzaak: te weinig Lambda-geheugen, of launch-args missen flags zoals --disable-gpu.
Oplossing: zet het geheugen op minstens 1024 MB (ik zou hoger gaan — zie de benchmarks hieronder) en zorg dat je chromium.args doorgeeft in plaats van een uitgeklede custom lijst.
Werkende code breekt na een Lambda runtime-update
Oorzaak: AWS patcht periodiek de onderliggende runtime, waardoor shared library-versies of Node.js patchversies onder je code vandaan kunnen schuiven.
Oplossing: pin je @sparticuz/chromium-versie expliciet, pin je Node-runtimeversie in de functieconfiguratie, en — dit is het deel dat mensen overslaan — test opnieuw na elke AWS-runtime-aankondiging, niet pas wanneer er iets breekt.
"Protocol error: Connection closed" na ongeveer 30 seconden
Oorzaak: je Lambda-timeout is korter dan de tijd die de pagina nodig heeft om echt te laden en te renderen.
Oplossing: verhoog de timeout naar 60–120 seconden, zet page.setDefaultNavigationTimeout() expliciet, en vervang waitUntil: 'networkidle0' door waitUntil: 'domcontentloaded' als je niet wilt wachten tot elk netwerkverzoek volledig is afgerond.
Productie-hardening: geheugen, cold starts en kosten
Veel gidsen zeggen alleen: “verhoog het geheugen”. Dat is geen bruikbaar advies — hier is wat er echt verandert als je meer geheugen toewijst.
Geheugen versus performance
Lambda kent CPU toe in verhouding tot geheugen, en dat detail gaat vaak mis. Meer geheugen betekent niet alleen “meer RAM om mee te werken”, maar ook snellere CPU, wat Chromium direct sneller laat renderen. In de praktijk zien teams die Puppeteer benchmarken merkbaar betere prestaties als ze van 512 MB naar 1536–2048 MB gaan, al hangt jouw exacte resultaat sterk af van de pagina’s die je rendert. In plaats van hier een benchmarktabel te geven die tegen de tijd dat je dit leest alweer verouderd is, kun je beter zelf een test draaien op 512 MB, 1024 MB, 1536 MB en 2048 MB tegen je echte doelpagina’s — tien minuten werk dat je precies laat zien waar jouw ideale balans tussen kosten en performance ligt.
Provisioned Concurrency voor cold starts
Als je iets latency-gevoeligs draait — synthetische monitoring, een real-time screenshot-API — dan zijn cold starts je vijand. Provisioned Concurrency houdt een vast aantal execution environments warm en klaar, zodat je de cold-start-penalty elimineert tegen de prijs van betalen voor die idle capaciteit. Dat is vooral de moeite waard als latency belangrijker is dan pure kostenefficiëntie.
arm64 (Graviton) voor kostenbesparing
Lambda-functies op basis van Graviton zijn ongeveer 20% goedkoper dan hun x86_64-tegenhangers. De kanttekening: arm64-ondersteuning van @sparticuz/chromium was historisch beperkter dan x86_64, dus controleer dat expliciet voor jouw vastgepinde versie voordat je Graviton in productie kiest.
VPC versus geen VPC
Je functie in een VPC plaatsen zorgde vroeger voor merkbaar extra cold-start-latency; AWS heeft die kloof de afgelopen jaren grotendeels gedicht, maar hij is nog steeds niet nul. Zet je functie alleen in een VPC als die echt naar private resources zoals RDS of ElastiCache moet — anders kun je het beter overslaan.
Wanneer je helemaal van Lambda af moet
Als je browsertaken regelmatig langer dan 15 minuten duren, meer dan 10 GB geheugen nodig hebben of persistente browsersessies over meerdere requests vereisen, dan vecht Lambda tegen je. ECS Fargate is precies daarvoor gebouwd: langlopende compute met configureerbare resources en betaling per seconde. Lambda is fantastisch voor korte, piekende en paralleliseerbare browsertaken; het is de verkeerde tool zodra je workload meer op een permanente service begint te lijken.
Wanneer Puppeteer op Lambda de verkeerde aanpak is
Dit is iets om eerlijk bij stil te staan: een groot deel van de developers die op “Puppeteer + Lambda”-gidsen uitkomt, probeert eigenlijk een data-extractieprobleem op te lossen, niet een browserautomatiseringsprobleem. Als je eigenlijk gestructureerde data uit webpagina’s nodig hebt — productlijsten, contactgegevens, paginainhoud — dan is al dat Chromium-packaging-, versie-pinnen- en layer-management hierboven vooral overhead die je niet had hoeven nemen.
Blijf bij Lambda + Puppeteer als je echte browsercontrole nodig hebt: interactieve formulieren, screenshot-/PDF-pipelines, synthetische monitoring of browsergebaseerde tests waarbij je de DOM echt programmatisch manipuleert.
Overweeg een scraping API als je einddoel gestructureerde JSON uit een webpagina is, en niet een browserversie die je zelf bestuurt. Thunderbit’s Open API verwerkt JavaScript-rendering, anti-botmaatregelen en CAPTCHA’s achter één HTTP-call — POST /extract met een JSON Schema levert gestructureerde data op, POST /distill geeft je nette Markdown. Er is ook een MCP-server (thunderbit_extract, thunderbit_distill) als je een AI-agent bouwt die onderweg data moet ophalen zonder zelf een browser te starten.
| Factor | Lambda + Puppeteer (zelf bouwen) | Extractie-API (bijv. Thunderbit) |
|---|---|---|
| Opzetduur | Uren (packaging, layers, debuggen) | Minuten (API-key + HTTP-call) |
| Onderhoud | Doorlopend (versies pinnen, runtime-updates) | Door de provider geregeld |
| Anti-botafhandeling | Handmatig (stealth plugins, proxies) | Ingebouwd |
| Output-formaat | Ruwe HTML/screenshots die je zelf verwerkt | Gestructureerde JSON via schema |
| Beste voor | Volledige browserautomatisering, tests, custom flows | Data-extractie, scraping, content-ingestie |
Ik zeg het graag heel direct: als je uren kwijt bent aan het debuggen van Chromium-binaries terwijl je alleen JSON uit productpagina’s wilt halen, dan los je waarschijnlijk het verkeerde probleem op. Bewaar de doe-het-zelf Lambda-route voor wanneer je echt een browser moet aansturen — voor extractie is er een directere weg. Als je deze afweging maakt voor een specifiek project, dan loopt onze handleiding voor AI-webscrapers dieper door het landschap heen, en de Thunderbit Chrome-extensie is het bekijken waard als je de extractie-eerst-aanpak eerst wilt testen voordat je een van beide routes kiest.
Afronding
Drie deploymethodes, één terugkerend thema: pin je versies, geef Chromium genoeg geheugen om te ademen, en kies de deploymethode op basis van je echte beperkingen — niet op basis van de eerste tutorial die je tegenkomt. Layers voor snelle iteratie, Container Images voor productie op schaal, ZIP voor een eenvoudige eenmalige job. En als je eigenlijk vooral data wilt extraheren in plaats van browserautomatisering te bouwen, is het misschien slim om te kijken of een speciaal gebouwde extractie-API je de verpakkingshoofdpijn volledig bespaart.
FAQ's
Kun je in 2026 Puppeteer op AWS Lambda draaien?
Ja — met puppeteer-core in combinatie met @sparticuz/chromium, uitgerold via Layers, Container Images of een directe ZIP. De volledige puppeteer-package en de verouderde chrome-aws-lambda-package werken niet meer betrouwbaar op recente Lambda-runtimes.
Wat is de maximale pakketgrootte voor AWS Lambda? 250 MB ongecomprimeerd voor Layers en ZIP-deployments; 10 GB voor Container Image-deployments, volgens de AWS Lambda quotas.
Wordt chrome-aws-lambda nog onderhouden?
Nee. De originele chrome-aws-lambda-package (van alixaxel) is deprecated en breekt op Node 18+. Gebruik in plaats daarvan @sparticuz/chromium — dat is op dit moment de actief onderhouden standaard.
Hoeveel geheugen heeft Puppeteer nodig op AWS Lambda? 1024 MB is in de praktijk het minimum; 1536–2048 MB is waar de performance echt comfortabel wordt. Onder de 1024 MB kun je duidelijk tragere uitvoering verwachten, omdat Lambda CPU toewijst op basis van geheugen.
Hoe verminder ik cold-starttijden voor Puppeteer op Lambda? Geef meer geheugen toe, omdat je daarmee ook meer CPU krijgt; overweeg Provisioned Concurrency als latency voor jouw use case kritisch is; en houd je deploypakket zo licht mogelijk — elke extra dependency kost extra cold-starttijd.
