If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/lambci/docker-lambda shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 3y ago

• 6 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Single-maintainer risk — top contributor 95% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live lambci/docker-lambda repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/lambci/docker-lambda.

What it runs against: a local clone of lambci/docker-lambda — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in lambci/docker-lambda | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1240 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of lambci/docker-lambda. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/lambci/docker-lambda.git
#   cd docker-lambda
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of lambci/docker-lambda and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "lambci/docker-lambda(\\.git)?\\b" \\
  && ok "origin remote is lambci/docker-lambda" \\
  || miss "origin remote is not lambci/docker-lambda (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "base/Dockerfile" \\
  && ok "base/Dockerfile" \\
  || miss "missing critical file: base/Dockerfile"
test -f "base/base-2/Dockerfile" \\
  && ok "base/base-2/Dockerfile" \\
  || miss "missing critical file: base/base-2/Dockerfile"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "base/runtimes.sh" \\
  && ok "base/runtimes.sh" \\
  || miss "missing critical file: base/runtimes.sh"
test -f ".github/workflows/ci-build.yml" \\
  && ok ".github/workflows/ci-build.yml" \\
  || miss "missing critical file: .github/workflows/ci-build.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1240 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1210d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/lambci/docker-lambda"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

docker-lambda provides Docker images that replicate the AWS Lambda runtime environment locally, including installed libraries, file structure, permissions, environment variables, and user context. It supports multiple runtimes (Python, Node.js, Go, Java, C#, Ruby) and allows developers to run and test Lambda functions identically to production, or use it as a build environment to compile native dependencies against the exact library versions deployed on AWS Lambda. Monorepo structure: /base contains the Dockerfile definitions for runtime images (base/, build/, base-2/, build-2/) and dump utilities (dump-go1x/, dump-java11/, dump-dotnetcore*/, etc.) that extract environment metadata from actual AWS Lambda. CI/workflows in .github/workflows/ run build and test pipelines. Language-specific code is minimal; the core is Dockerfile-driven.

AWS Lambda developers and DevOps engineers who need to test Lambda functions locally before deployment, or who need to build native extension dependencies (C extensions, system libraries) that will run on Lambda's specific OS and library versions.

This project is archived and deprecated. The README explicitly states it's no longer maintained in favor of AWS's official lambda base images (aws/aws-lambda-base-images). The repo was mature and production-ready when active, but is now unmaintained.

High risk for new adoption: Project is explicitly archived with no further updates planned. AWS recommends migrating to official images at https://gallery.ecr.aws/lambda/. Existing users depend on pinned image tags, but any future compatibility issues with newer Docker or AWS API changes will not be fixed.

Nothing. Project is archived. Last activity was sunset work directing users to AWS official images. No active PRs or development.

Clone and explore existing images:

git clone https://github.com/lambci/docker-lambda.git
cd docker-lambda
cat README.md  # Understand deprecation notice
cat base/Dockerfile  # Review runtime base image structure

Note: Do not use for new projects; migrate to https://gallery.ecr.aws/lambda/ instead.

Daily commands: Not a runnable application. It is a Docker image builder. To use the images (deprecated—not recommended):

# Example: run a Python Lambda locally
docker run --rm \
  -v $(pwd)/myfunction:/var/task:ro \
  -e DOCKER_LAMBDA_STAY_OPEN=1 \
  lambci/lambda:python3.8 \
  index.handler '{"key": "value"}'

To rebuild images locally (requires Docker):

cd base && bash build-all.sh

• base/Dockerfile — Root Docker image for Lambda AL1 runtime; all runtime-specific Dockerfiles build upon this, defining the base OS, system packages, and Lambda runtime initialization.
• base/base-2/Dockerfile — AL2-based foundation image; required reading to understand the architecture split between Amazon Linux 1 and AL2 runtimes and their differing dependency stacks.
• README.md — Project overview and usage guide; explicitly states the repo is deprecated in favor of AWS official images, critical context for all contributors.
• base/runtimes.sh — Central script defining all supported Lambda runtime versions (Node, Python, Ruby, Go, Java, .NET, provided); single source of truth for runtime matrix.
• .github/workflows/ci-build.yml — Automated Docker image build and publish pipeline; defines how images are versioned, tagged, and deployed to registries.
• base/dump-nodejs.js — Example dumper script for Node.js runtime; establishes the pattern for extracting Lambda environment metadata (packages, env vars, layer structure) used across all runtime dumps.

• Base Dockerfile (base/Dockerfile, base/base-2/Dockerfile) —

Add Support for a New Lambda Runtime Version

1. Define the new runtime version in base/runtimes.sh, adding it to the appropriate language array and TAG variable (base/runtimes.sh)
2. Create or update a runtime dumper script (e.g., base/dump-python39.py) that extracts environment metadata using boto3 or equivalent Lambda SDK (base/dump-python39.py)
3. Run base/dump.sh to generate package inventory files (.txt) that document the runtime's installed dependencies (base/dump.sh)
4. Update base/Dockerfile or base/base-2/Dockerfile to add installation steps for the new runtime (package dependencies, SDK installation) (base/Dockerfile)
5. Trigger base/build-all.sh locally or push to master to invoke the CI/CD pipeline in .github/workflows/ci-build.yml, which will build and publish the new image (base/build-all.sh)

Create a Package Inventory / Environment Documentation for a Runtime

1. Write a dumper script (bash, Python, Go, etc.) that calls AWS Lambda APIs or introspects the runtime environment (e.g., node -e 'console.log(JSON.stringify(process.versions))') (base/dump-nodejs.js)
2. Execute the dumper within the target runtime container to generate .txt output files documenting installed packages and environment state (base/dump.sh)
3. Commit the resulting inventory files (e.g., base/packages.txt) to track what libraries exist in each runtime version for reproducibility (base/packages.txt)

Build and Test a Runtime Image Locally

1. Edit the target Dockerfile (base/Dockerfile, base/base-2/Dockerfile, base/build/Dockerfile) to modify system packages, runtime versions, or environment setup (base/Dockerfile)
2. Run base/build-all.sh or docker build directly on the Dockerfile to compile the image locally (base/build-all.sh)
3. Run a test container using docker run with the built image and your Lambda function handler to verify behavior matches AWS (base/native-test.sh)
4. Verify the image is properly tagged and push it via base/publish-all.sh or manual docker push (base/publish-all.sh)

• Docker & Dockerfiles — Primary mechanism to package and distribute exact replicas of AWS Lambda runtimes; enables reproducible local testing across all Lambda versions
• Amazon Linux 1 & 2 base OS — Matches the exact OS kernels and system libraries used in real AWS Lambda environments; critical for native dependency compilation and system behavior
• GitHub Actions CI/CD (ci-build.yml, ci-run.yml) — Automates build and publish workflows; keeps images synchronized with Lambda runtime updates and distributes them to registries on schedule
• Multi-language dumper scripts (Node.js, Python, Go, Java, .NET, Ruby) — Extracts and documents runtime-specific environment state (packages, versions, env vars) so containers remain synchronized with live Lambda
• ECR Public (AWS Elastic Container Registry) — Primary distribution channel for images; integrates with AWS ecosystem and provides high-availability, bandwidth-optimized delivery

• Deprecated in favor of AWS official images (aws/aws-lambda-base-images)

  • Why: AWS now publishes official, supported Lambda base images, making community maintenance redundant and risky
  • Consequence: This repo is archived; new features/fixes will not be implemented. Users should migrate to official images for security and support.

• Separate AL1 and AL2 image trees (base/ vs base-2/)

  • Why: AWS Lambda supports both older AL1 and newer AL2 runtimes with different package versions and system libraries
  • Consequence: Doubles maintenance burden; each feature/fix must be applied to both branches, but enables testing against both real Lambda environments

• Dumper scripts in multiple languages rather than unified metadata format

  • Why: Each runtime has language-specific introspection APIs and tooling; using native tooling ensures highest fidelity
  • Consequence: Harder to unify and compare environments across runtimes, but guarantees accuracy for each language's specific context

• Does not provide real-time synchronization with AWS Lambda runtime updates; relies on manual dumper runs and CI schedules
• Not a testing framework; does not include test runners or assertion libraries (users bring their own test code)
• Does not handle authentication, secrets management, or AWS credentials; users must inject these via environment or mounts
• Does not emulate AWS services (DynamoDB, S3, SQS, etc.); only replicates the Lambda execution environment itself

Critical: This repo is archived and deprecated. AWS official images should be used instead (https://gallery.ecr.aws/lambda/). Image tags reference runtime versions that may not match current AWS Lambda runtimes. Docker Hub image tags (lambci/lambda:*) are frozen; no updates occur. Dockerfile dependencies on amazonlinux base images (which are mutable) mean image rebuilds may produce different results. DOCKER_LAMBDA_STAY_OPEN environment variable expected by API mode (port 9001) is non-standard.

• Container image layer caching — docker-lambda's Dockerfile hierarchy (base → runtime-specific layers) depends on Docker's layer caching for fast rebuilds; understanding this is critical to modifying build times and image size.
• Amazon Linux filesystem and package manifests — The dump-* utilities and .txt files (amazonlinux1.txt, amazonlinux2.txt, packages.txt) document the exact /proc, /etc, and yum package list from AWS Lambda; critical to understanding what libraries are available at runtime.
• Lambda runtime API and invocation model — docker-lambda's DOCKER_LAMBDA_STAY_OPEN mode implements AWS Lambda's Runtime API to simulate how Lambda invokes handlers; understanding this API is key to local testing accuracy.
• Multi-stage Docker builds — base/ and build/ Dockerfiles use two-stage approach (base image + build layer); this pattern reduces final image size and allows build-time dependencies to be stripped.
• Environment variable isolation in containerized runtimes — docker-lambda exposes AWS_LAMBDA_FUNCTION_NAME, AWS_LAMBDA_LOG_GROUP_NAME, and other AWS-specific env vars; understanding which vars are injected helps developers replicate production Lambda behavior locally.
• Native dependency compilation for Lambda — The build images are specifically designed for compiling C/C++ extensions, Rust, or Go binaries that will run on Lambda's amazonlinux environment; mismatched libc or glibc versions cause runtime failures.

• aws/aws-lambda-base-images — The official successor to docker-lambda, maintained by AWS; use this for new Lambda container image development.
• aws/aws-lambda-python-runtime — Official AWS Lambda Python runtime source; defines actual Python environment deployed to production.
• aws/aws-lambda-nodejs-runtime — Official AWS Lambda Node.js runtime source; defines actual Node.js environment deployed to production.
• localstack/localstack — Alternative local AWS service emulator; provides Lambda mocking alongside DynamoDB, S3, etc., but uses different container approach.
• serverless/serverless — Serverless Framework for managing Lambda deployments; often paired with local testing tools like docker-lambda or SAM.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for .NET Core runtimes (dotnetcore20, dotnetcore21, dotnetcore31)

The repo contains dump utilities for three .NET Core versions (base/dump-dotnetcore20/, base/dump-dotnetcore21/, base/dump-dotnetcore31/) but there are no visible test files in .github/workflows/ that verify these Docker images can successfully compile and run .NET Lambda functions. Given that the project replicates the live AWS Lambda environment, adding runtime validation tests would ensure .NET runtimes work identically to AWS.

• [ ] Create .github/workflows/ci-dotnet-test.yml workflow file
• [ ] Add test scripts in base/ that build and run sample .NET functions using the existing dump projects
• [ ] Verify csproj files compile correctly and output matches AWS Lambda behavior
• [ ] Add assertions for .NET runtime environment variables and permissions

Add migration guide from docker-lambda to AWS official images

The README states the project is deprecated in favor of AWS official images (github.com/aws/aws-lambda-base-images), but users upgrading from docker-lambda will face breaking changes in image structure, tags, and APIs. A migration guide section in README.md would reduce friction for the large user base transitioning to official images.

• [ ] Add 'Migration Guide' section in README.md after the deprecation notice
• [ ] Document tag mapping (e.g., lambci/lambda:python3.8 → public.ecr.aws/lambda/python:3.8)
• [ ] List breaking changes in entrypoint, environment variables, and file structure
• [ ] Provide side-by-side examples of running functions with old vs new images

Create a validation script to verify Go runtime outputs match AWS Lambda (base/dump-go1x/)

The base/dump-go1x/ directory contains a Go dumper utility but unlike the .NET and Java counterparts with their own directories, there's no corresponding test or validation script in the CI workflows for Go runtimes. The go.mod file references aws-lambda-go v1.13.3, but there's no automated verification that the Go runtime behavior in docker-lambda matches live Lambda.

• [ ] Create base/create-dump-go1x.sh script to execute dump-go1x and capture environment/binary info
• [ ] Add Go runtime test to .github/workflows/ci-run.yml to build and execute sample Go Lambda functions
• [ ] Compare outputs (environment variables, loaded libraries) against expected AWS Lambda Go runtime behavior
• [ ] Document any differences found between docker-lambda Go runtime and official AWS behavior

Do not contribute—repo is archived. If historical understanding needed: (1) Update dump-* utilities and amazonlinux*.txt to document differences in a newer language runtime (e.g., Python 3.11) vs. current base, (2) Add missing test coverage in .github/workflows/ci-run.yml for edge cases (e.g., Lambda layer mocking), (3) Document migration examples from docker-lambda to aws/aws-lambda-base-images in a MIGRATION.md file. But these are not active—contribute to AWS official images instead.

The docker-lambda repository has significant security concerns. Most critically, it is archived and deprecated with no active maintenance, making it unsuitable for production use. The Go dependencies are severely outdated (2+ years old) with likely unpatched vulnerabilities. The project lacks modern security practices including container scanning, vulnerability management, and supply chain security measures. Users should migrate to AWS' official Lambda base images immediately. For any continued use of this codebase, comprehensive dependency updates and security scanning implementation are essential.

• High · Archived Project with No Active Maintenance — README.md. The repository is explicitly marked as deprecated and archived in the README. It will not receive any further updates, security patches, or maintenance. Using this project in production exposes users to unpatched vulnerabilities and security issues. Fix: Migrate to AWS' official Lambda base images available at https://github.com/aws/aws-lambda-base-images or https://gallery.ecr.aws/lambda/python for actively maintained and supported solutions.
• High · Outdated Go Dependency Version — base/dump-go1x/go.mod. The dump-go1x module uses aws-lambda-go v1.13.3 (released June 2020) and aws-sdk-go-v2 v0.17.0 (released August 2020). These versions are significantly outdated and likely contain known security vulnerabilities. Fix: Update to the latest versions of aws-lambda-go and aws-sdk-go-v2. Run 'go get -u github.com/aws/aws-lambda-go' and 'go get -u github.com/aws/aws-sdk-go-v2' to fetch current versions, then audit with 'go list -json -m all | nancy sleuth'.
• Medium · Outdated Go Runtime Version — base/dump-go1x/go.mod. The go.mod file specifies 'go 1.15', which was released in August 2020 and is well past its end-of-life date (March 2021). Go 1.15 no longer receives security patches. Fix: Update to a currently supported Go version (1.21 or later). Modify the go.mod file to use 'go 1.21' or higher and rebuild dependencies.
• Medium · Missing Container Security Scanning — .github/workflows/. The GitHub Actions workflows (ci-build.yml, ci-run.yml) show no evidence of container image scanning, vulnerability scanning (e.g., Trivy, Snyk), or signed images. This means images could contain vulnerabilities without detection. Fix: Implement automated container vulnerability scanning in CI/CD pipelines using tools like Trivy, Snyk, or AWS ECR image scanning. Add container image signing and verification.
• Low · No SBOM (Software Bill of Materials) Generation — Repository root. The repository does not appear to generate SBOMs for Docker images or compiled artifacts, making supply chain security and vulnerability tracking difficult. Fix: Generate and publish SBOMs for all Docker images using tools like syft. Include SBOM generation in the build pipeline.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.