In serverless and edge platforms, the vendor patches the runtime and you patch your dependencies. The packaging choice, whether zip, layer, container or bundle, decides how fast you can do that. The answers below are short, tied to vendor documentation, and link to longer posts.
Who patches what
Does the platform patch my npm or pip packages? No. AWS's Node.js packaging guidance says that under the shared responsibility model you manage the dependencies in your deployment package. Cloudflare's runtime updates do not rewrite your bundle either. See Workers runtime updates versus dependency updates.
Does a container Lambda pick up a new base image on its own? No. AWS says you must rebuild the image and update the function. See rebuilding after a base image update.
Packaging
How big can a Lambda zip be? AWS lists 50 MB zipped through the API or SDKs and 250 MB unzipped including layers, and 10 GB for container images. See package size limits.
How many layers can one function use? Five, per AWS. See what to do at the limit.
Should Go or Rust functions use layers? AWS recommends against it. See why.
Can I convert a zip function to a container? Not in place. See the migration plan.
Edge specifics
Which edge option can carry libraries? CloudFront Functions allow 10 KB of code and libraries, and Lambda@Edge allows 50 MB. See where dependencies fit.
Can Lambda@Edge use layers? No. See what Lambda@Edge does not support.
Which npm packages run on Vercel's Edge runtime? ES module packages that avoid native Node.js APIs and eval. See the compatibility rules.
Runtimes and lifecycle
What happens when a runtime is deprecated? On Cloud Run functions you get notice about 90 days ahead, and after decommission you cannot update. See the lifecycle. For Azure Functions, see the current support status.
A one page summary
| Platform | You patch | The platform patches |
|---|---|---|
| Lambda zip | Packages in the zip and layers | Managed runtime, per your update setting |
| Lambda container | Everything in the image | AWS publishes base images, you rebuild |
| Lambda@Edge | Packages in the zip | Runtime, Auto mode only |
| CloudFront Functions | Your small script | The runtime |
| Cloudflare Workers | Packages in the bundle | The Workers runtime |
| Vercel Edge | Packages in the bundle | The edge runtime |
The pattern is the same everywhere: anything inside your artifact is yours.
What to do first
- List every function and where it runs.
- Record the package source for each one: lockfile, SBOM or image.
- Scan on every build and on a schedule.
- Give each function an owner and a runtime end date.
Try it yourself
Open the demo and trace one package across services. Doing this once makes the rest of the list concrete.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis and asset discovery for the source and builds behind your functions. Free scan: gold.safeguard.sh/scan.
Quick check
What is the one rule that holds across platforms?
Whatever is inside the artifact you upload is yours to patch. The platform handles the runtime.
Where do I start if I have hundreds of functions?
Build the inventory first, then rank by internet exposure and runtime end date.
Sources
- Deploy Node.js Lambda functions with .zip file archives, AWS documentation
- Lambda quotas, AWS documentation
- Differences between CloudFront Functions and Lambda@Edge, AWS documentation
- Limits, Cloudflare Workers documentation
- Runtime support, Cloud Run functions documentation
Last reviewed: 19 October 2026.
