No. A cold start creates a fresh execution environment, but it loads the same deployment package, layers and configuration your function version already had. Lambda patches the managed runtime for you. Libraries inside your package or layers are yours to update and redeploy.
Why people expect a restart to fix things
Serverless feels self-healing. Environments come and go, and the AWS documentation says Lambda terminates execution environments every few hours to allow for runtime updates and maintenance, even for functions that are invoked continuously. It is easy to read that as "everything refreshes on its own."
The refresh is real, but it covers the platform layer. When a new environment starts, it downloads your code and layers, starts extensions, boots the runtime and runs your initialization code. Nothing in that sequence swaps in newer versions of the packages you shipped.
What changes and what does not
| Item | Changes on a cold start? | Who updates it |
|---|---|---|
| Managed runtime security patches | Yes, through Lambda runtime updates | Lambda, in Auto mode |
| Operating system libraries in the runtime | Yes, as part of runtime versions | Lambda |
| Packages in your .zip or container image | No | You |
| Packages in a layer version | No, layer versions are immutable | You, by publishing and attaching a new version |
| Runtime included SDK, if you rely on it | Can change when the runtime updates | Lambda, which can surprise you |
The AWS shared responsibility table says the same thing in plain terms: on a supported managed runtime, your responsibility is to update your function code, including dependencies, to address security vulnerabilities.
A quick way to prove it to yourself
Pick a function, note the version of one package in its bundle, and invoke it after forcing a new environment (for example by changing an environment variable). Log the package version at startup. It will match what you deployed, because the version is part of the artifact.
If you want a patched dependency to run, the sequence is always the same:
- Update the version in your manifest and lockfile.
- Rebuild the package or image.
- Publish a new function version, or update layers and attach the new layer version.
- Move aliases or traffic to the new version.
- Confirm the new version is the one receiving invocations.
The one place a restart can matter
If your function relies on the SDK that ships inside the runtime rather than bundling its own, a runtime update can change that SDK. AWS recommends including the SDK modules your code uses in your deployment package or a layer, to keep control of dependencies and avoid compatibility surprises during automatic runtime updates. That advice is about stability first, but it also makes your security posture predictable: the version you tested is the version that runs.
Try it yourself
Click through it at your own pace, or open it full screen.
Click into a package and look at which version is pinned. That pinned version is what a cold start will load again.
Quick check
Does Lambda patch Node or Python libraries I installed myself?
No. Lambda updates the managed runtime. Packages you installed into the deployment package or a layer stay at the version you shipped until you rebuild and redeploy.
Is a restart a reasonable way to apply a runtime patch?
You do not need to force one. In Auto mode Lambda rolls runtime updates out for you. In Function update mode, the new runtime version arrives when you update the function.
If you keep a list of what you deploy, Safeguard's SBOM and dependency scanning can flag vulnerable versions in that list, and reachability analysis helps you decide which ones to fix first. You can try a free scan at gold.safeguard.sh/scan.
Sources
- AWS Lambda execution environment lifecycle
- AWS Lambda runtimes and shared responsibility
- How Lambda manages runtime version updates
Last reviewed: 19 October 2026.
