Fix InvalidParameterValueException for AWS Lambda docker images built by GitHub Actions

If you're using GitHub Actions to build Docker images for AWS Lambda functions, you might encounter the following error: InvalidParameterValueException: The image manifest, config or layer media type for the source image \\\.dkr.ecr.\\\.amazonaws.com/myrepository/myimage:latest is not supported. This error is confusing at first glance — especially if you’ve successfully used the same image with EKS, ECS or other docker-based environments. Here’s what’s going on under the hood. TL;DR GitHub Actions (docker/build-push-action@v4) builds OCI images by default with provenance and sbom enabled. However, AWS Lambda only supports Docker v2 manifests — not OCI. To fix the error, disable those features in your GitHub action step: provenance: false sbom: false Root Cause: OCI vs Docker Image Format Starting with version 4, docker/build-push-action builds images using the OCI format by default. OCI (Open Container Initiative) is the modern standard that is supported by AWS ECR. However, AWS Lambda does not support OCI image manifests. Lambda only accepts the older Docker v2 schema: application/vnd.docker.distribution.manifest.v2+json That’s why your image may push to ECR fine but still fail at deployment to Lambda with InvalidParameterValueException error. After pushing the image to ECR, you will see something like this in the metadata: Why Lambda Doesn’t Support OCI While ECR and ECS support OCI images, Lambda does not— and here’s why: Lambda implemented container image support in 2020, using the Docker v2 image spec, which was the most stable and frequently used format at the time. Performance and security constraints: Lambda is designed for quick cold starts and strict security. Supporting full OCI manifests (particularly with SBOMs and provenance metadata) may raise complexity, slow down startup, or expose new attack vectors. Lambda is not a general container runtime: Lambda's runtime mechanism is restricted, unlike ECS or EKS, which are designed to execute arbitrary containers. Supporting a wider range of image formats is not a priority. Solution To remedy the image manifest format issue, modify the docker/build-push-action@v4 step in your GitHub job file as follows: - name: Build and push Lambda image uses: docker/build-push-action@v4 with: context: . push: true tags: | latest provenance: false sbom: false Setting both provenance: false and sbom: false disables features that require OCI format, thereby enabling Docker v2 manifest compatibility. This results in your image being built with the proper media type,application/vnd.docker.distribution.manifest.v2+json which Lambda can consume without trouble. What are provenance and sbom options? In GitHub Actions, the Docker Buildx plugin now enables two features by default: provenance: true — enables Software Supply Chain Provenance, which attaches build metadata to the image (as per SLSA standards). sbom: true — enables generation of SBOMs (Software Bill of Materials), a key part of software supply chain security. Service Compatibility Overview Final Thoughts While OCI represents the future of container image standards, AWS Lambda has yet to catch up to it. If you're deploying Lambda functions using GitHub Actions, make sure your image builds are Docker-compatible via modifying the provenance and sbom settings.

Mar 31, 2025 - 11:07

Fix InvalidParameterValueException for AWS Lambda docker images built by GitHub Actions

If you're using GitHub Actions to build Docker images for AWS Lambda functions, you might encounter the following error:

InvalidParameterValueException: The image manifest, config or layer media type for the source image \*\*\*.dkr.ecr.\*\*\*.amazonaws.com/myrepository/myimage:latest is not supported.

This error is confusing at first glance — especially if you’ve successfully used the same image with EKS, ECS or other docker-based environments. Here’s what’s going on under the hood.

TL;DR

GitHub Actions (docker/build-push-action@v4) builds OCI images by default with provenance and sbom enabled. However, AWS Lambda only supports Docker v2 manifests — not OCI. To fix the error, disable those features in your GitHub action step:

provenance: false 
sbom: false

Root Cause: OCI vs Docker Image Format

Starting with version 4, docker/build-push-action builds images using the OCI format by default. OCI (Open Container Initiative) is the modern standard that is supported by AWS ECR. However, AWS Lambda does not support OCI image manifests. Lambda only accepts the older Docker v2 schema: application/vnd.docker.distribution.manifest.v2+json

That’s why your image may push to ECR fine but still fail at deployment to Lambda with InvalidParameterValueException error. After pushing the image to ECR, you will see something like this in the metadata:

Why Lambda Doesn’t Support OCI

While ECR and ECS support OCI images, Lambda does not— and here’s why:

Lambda implemented container image support in 2020, using the Docker v2 image spec, which was the most stable and frequently used format at the time.
Performance and security constraints: Lambda is designed for quick cold starts and strict security. Supporting full OCI manifests (particularly with SBOMs and provenance metadata) may raise complexity, slow down startup, or expose new attack vectors.
Lambda is not a general container runtime: Lambda's runtime mechanism is restricted, unlike ECS or EKS, which are designed to execute arbitrary containers. Supporting a wider range of image formats is not a priority.

Solution

To remedy the image manifest format issue, modify the docker/build-push-action@v4 step in your GitHub job file as follows:

- name: Build and push Lambda image
 uses: docker/build-push-action@v4
 with:
   context: .
   push: true
   tags: |
     latest
   provenance: false
   sbom: false

Setting both provenance: false and sbom: false disables features that require OCI format, thereby enabling Docker v2 manifest compatibility.

This results in your image being built with the proper media type,application/vnd.docker.distribution.manifest.v2+json which Lambda can consume without trouble.

What are `provenance` and `sbom` options?

In GitHub Actions, the Docker Buildx plugin now enables two features by default:

provenance: true — enables Software Supply Chain Provenance, which attaches build metadata to the image (as per SLSA standards).
sbom: true — enables generation of SBOMs (Software Bill of Materials), a key part of software supply chain security.

Service Compatibility Overview

Final Thoughts

While OCI represents the future of container image standards, AWS Lambda has yet to catch up to it. If you're deploying Lambda functions using GitHub Actions, make sure your image builds are Docker-compatible via modifying the provenance and sbom settings.