Skip to content

chore(deps): update swift aws lambda runtime - #16

Merged
renovate[bot] merged 1 commit into
mainfrom
renovate/swift-aws-lambda-runtime
Jul 9, 2026
Merged

chore(deps): update swift aws lambda runtime#16
renovate[bot] merged 1 commit into
mainfrom
renovate/swift-aws-lambda-runtime

Conversation

@renovate

@renovate renovate Bot commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Update Change
awslabs/swift-aws-lambda-runtime minor from: "2.3.1" → from: "2.11.0"
swift-server/swift-aws-lambda-events minor from: "0.4.0" → from: "0.5.0"

Release Notes

awslabs/swift-aws-lambda-runtime (awslabs/swift-aws-lambda-runtime)

v2.11.0

Compare Source

This release contains two important changes. Please read the migration notes below before upgrading.

1. Amazon Linux 2023 is now the default build container

Starting June 30, 2026, Amazon Linux 2 has reached end of support. Following the plan described in #​668 and the Swift Forum discussion, the Swift Lambda Runtime plugins now use Amazon Linux 2023 (swift:<version>-amazonlinux2023) as the default base Docker image for cross-compiling your code.

[!WARNING]
Amazon Linux 2 and Amazon Linux 2023 ship different versions of glibc, so a binary built on AL2023 is not compatible with the provided.al2 runtime. When you compile on Amazon Linux 2023, you must update your deployment to Amazon Linux 2023 (provided.al2023) too:

  • SAM / CloudFormation: Runtime: provided.al2 → Runtime: provided.al2023
  • CDK: lambda.Runtime.PROVIDED_AL2 → lambda.Runtime.PROVIDED_AL2023

If you need to keep building for Amazon Linux 2 during the transition, you can still pass --base-docker-image swift:<version>-amazonlinux2 explicitly.

PR: #​675

2. New plugins available on Swift 6.4+

The new plugin system, lambda-init, lambda-build, and lambda-deploy (introduced in #​567), is now available, but requires Swift 6.4 or later. See the user guide in #​567.

TL;DR

mkdir test && cd test 

# Use Swift 6.4
swiftly use 6.4.x-snapshot

# Create a new project
swift package init --type executable --name MyLambda

# Add dependency on the Swift AWS Lambda Runtime
swift package add-dependency https://github.com/awslabs/swift-aws-lambda-runtime.git --from 2.11.0
swift package add-target-dependency AWSLambdaRuntime MyLambda --package swift-aws-lambda-runtime

# Scaffold a Lambda function
swift package lambda-init --allow-writing-to-package-directory

# Change Package.swift to 

# // swift-tools-version: 6.3
# This is temporary until an official swift:6.4-amazonlinux2023 will be available 

# Build for Amazon Linux
swift package --allow-network-connections docker lambda-build

# Deploy to AWS
swift package --allow-network-connections all:443 lambda-deploy

# Delete when done
swift package --allow-network-connections all:443 lambda-deploy --delete

Why Swift 6.4? The new plugins depend on soto-core, which transitively depends on swift-crypto. swift-crypto declares a minimum macOS platform requirement that is incompatible with this package, which intentionally does not declare a platforms: section (to avoid forcing platform minimums onto downstream packages). Prior to Swift 6.4, SwiftPM's hardcoded default macOS deployment target was too low to satisfy that requirement. Swift 6.4 raises SwiftPM's default macOS deployment target to v12, which satisfies swift-crypto and soto-core without us having to reintroduce a platforms: declaration. These plugins are therefore gated behind Swift 6.4.

Compatibility: The legacy archive plugin remains available on all supported Swift versions so your existing CI does not break. Please migrate to lambda-build when you move to Swift 6.4.

Something broken?

If this release breaks your build or deployment, please file an issue so we can help.

What's Changed

SemVer Minor
  • [plugin] v2: lambda-init, lambda-build, lambda-deploy by @​sebsto in #​567
  • [plugin] AmazonLinux2023 is now the default by @​sebsto in #​675
  • [plugin] docs: add "Using the SwiftPM Plugins" article by @​sebsto in #​677
  • [plugin] Fix: resolve the container CLI matching the cross-compile method (lambda-build & archive) by @​sebsto in #​678
  • [plugin] Refactor lambda-build into pluggable build backends + thin-layer plugin args by @​sebsto in #​679
  • [plugin] Move cross-compile backend factory to BuilderConfiguration; fix log handler deprecation warning by @​sebsto in #​680
  • [plugin] Refactor lambda-build packaging into a pluggable ArchiveBackend (ZIP today, OCI-ready) by @​sebsto in #​681
SemVer Patch
  • [plugin] Fix: lambda-deploy update path now verifies the execution role exists by @​sebsto in #​676
Other Changes

Full Changelog: awslabs/swift-aws-lambda-runtime@2.10.0...2.11.0

v2.10.0

Compare Source

What's new

Amazon Linux 2023 migration. The archive plugin now displays a deprecation warning when building on or for Amazon Linux 2. AL2 reaches End of Life on June 30, 2026, and the plugin default will switch to Amazon Linux 2023 after that date. To migrate today, add --base-docker-image swift:amazonlinux2023 to your archive command and update your Lambda deployment to use the provided.al2023 runtime. All examples have been updated to build and deploy on Amazon Linux 2023.

Dropped Swift 6.0 support. The library now requires Swift 6.1 or later, following the ecosystem policy of supporting the last three major versions (6.1, 6.2, 6.3).

Other changes
  • Replaced NIOLockedValueBox with Synchronization.Mutex, removing a workaround for a compiler crash that no longer applies.
  • Adopted swift-log's new log(event:) protocol method. The JSON log handler now also includes source and error fields in structured output, making it easier to filter logs in CloudWatch by module and spot errors without digging through metadata.
  • Removed Package@swift-6.0.swift and all #if compiler/#if swift guards that only existed to support 6.0.
  • Bumped minimum dependency versions (swift-nio, swift-log, swift-collections, swift-service-lifecycle).

v2.9.0

Compare Source

This releases add support for sharing the CloudWatch log name and log stream name, similar to the runtime interface client for other languages.

LambdaContext offers two new variables:

    /// The name of the Amazon CloudWatch Logs group for the function.
    public var logGroupName: String {
        self.storage.logGroupName
    }

    /// The name of the Amazon CloudWatch Logs stream for the current invocation of the function.
    public var logStreamName: String {
        self.storage.logStreamName
    }

You can use them with:

    context.logger.debug("Log Group Name = \(context.logGroupName)")
    context.logger.debug("Log Group Stream Name = \(context.logStreamName)")

What's Changed

SemVer Minor
Other Changes

Full Changelog: awslabs/swift-aws-lambda-runtime@2.8.0...2.9.0

v2.8.0

Compare Source

This releases adds support for JSON Structured Logging

JSON structured logging lets CloudWatch capture your Lambda logs as searchable key-value pairs instead of plain text, making it significantly easier to filter, query, and debug in production. It also enables you to attach metadata and contextual information (like request IDs or error codes) to each log entry, which is essential for automated analysis at scale. This is especially relevant since Lambda Managed Instances only support JSON log format — so this release brings the Swift runtime in line with that requirement.

Example of log entry:

{
    "message": "Server started and listening",
    "requestId": "N\/A",
    "level": "INFO",
    "timestamp": "2026-02-24T18:43:11.688Z",
    "metadata": {
        "port": "7000",
        "host": "\"127.0.0.1\""
    },
    "traceId": "N\/A",
    "file": "AWSLambdaRuntime\/Lambda+LocalServer.swift",
    "function": "withLocalServer(host:port:invocationEndpoint:eventLoopGroup:logger:_:)",
    "line": 168
}

There is nothing to change in your code to activate JSON Structured logging, this is a configuration at the function level either in the console, your IaC code, or the CLI when you create or update a function. Behind the scene, the Lambda service sets AWS_LAMBDA_LOG_FORMAT=JSON. Similarly, you can control the log level directly from the console or your IaC code.

We added an example in Examples/JSONLogging:

      LoggingConfig:
        LogFormat: JSON
        ApplicationLogLevel: DEBUG
        SystemLogLevel: INFO

The old behaviour of text-based logging and verbosity control through the LOG_LEVEL environment variable is preserved. This is a purely additive change.

Learn more about Lambda Structured Logging in the doc: https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs-logformat.html

Acknowledgements

I'd like to thank @​manojmahapatra and @​benrosen78 for their contributions on these two new capabilities.

What's Changed

SemVer Minor
SemVer Patch
Other Changes

Full Changelog: awslabs/swift-aws-lambda-runtime@2.7.0...2.8.0

v2.7.0

Compare Source

The archive plugin now supports Apple's container CLI as an alternative to Docker for building Lambda deployment packages.

Pass --container-cli container to use it instead of the default Docker path. The plugin translates commands accordingly, using container image pull and container run under the hood.

To use it:

swift package --disable-sandbox --allow-network-connections docker archive --container-cli container

Note that even when using Apple's container CLI, you still need to pass --allow-network-connections docker on the command line. This is a SwiftPM limitation, not something the plugin controls. In a future version, SPM will not prompt for specific authorization when --disable-sandbox is specified (see swiftlang/swift-package-manager#9763)

Docker remains the default. If you don't pass --container-cli, nothing changes.

What's Changed

SemVer Minor

Full Changelog: awslabs/swift-aws-lambda-runtime@2.6.3...2.7.0

v2.6.3

Compare Source

We fixed a bug and improved the life for those of you building on Amazon Linux 2023.

  • [bug] the local HTTP server you use for testing your functions locally was not forwarding the HTTP headers you passed to the Lambda function. This prevented you local testing of function that expects some specific HTTP headers or to test Lambda Multi Tenant. @​manojmahapatra fixed this and added a Multi Tenant example to show you how to pass test multi tenant functions locally, with curl. This is Manoj's first contribution to the project. Welcome and thank you.

  • [plugin] : the archive plugin now correctly recognises it runs on Amazon Linux 2023 and doesn't attempt to build with docker anymore. Thank you @​0xTim for having reported that.

As usual, let us know your feedback, comments, or suggestions.

What's Changed

SemVer Patch

New Contributors

Full Changelog: awslabs/swift-aws-lambda-runtime@2.6.2...2.6.3

v2.6.2

Compare Source

This is a patch release that fixes two rare concurrency issues. One was when using the swift package archive plugin. And the second one was when the server (Lambda control plane) closes the HTTP connection, which practically never happens, except when using the local HTTP server during your tests.

I observed these problems mostly in our CI/CD pipeline.

Let us know if you also experimented crashes when the server closes the HTTP connection or with the archive plugin.

What's Changed

SemVer Patch

Full Changelog: awslabs/swift-aws-lambda-runtime@2.6.1...2.6.2

v2.6.1

Compare Source

Add a Swift docc page to cover Lambda Managed Instances introduced in release 2.6.0

It will eventually be available at https://swiftpackageindex.com/awslabs/swift-aws-lambda-runtime/~/documentation/awslambdaruntime

What's Changed

SemVer Patch

Full Changelog: awslabs/swift-aws-lambda-runtime@2.6.0...2.6.1

v2.6.0

Compare Source

Lambda Managed Instances Support

We're excited to announce support for AWS Lambda Managed Instances in the Swift AWS Lambda Runtime. This new deployment model enables you to run Lambda functions on your current-generation Amazon EC2 instances while maintaining serverless simplicity.

What are Lambda Managed Instances?

Lambda Managed Instances provide EC2 flexibility and cost optimization by running your functions on customer-owned EC2 instances. AWS handles all infrastructure management tasks including instance lifecycle, OS and runtime patching, routing, load balancing, and auto-scaling. The key difference from traditional Lambda is support for concurrent invocations within the same execution environment, allowing multiple requests to be processed simultaneously on the same host.

When to Use Lambda Managed Instances

Lambda Managed Instances are ideal for:

  • Sustained workloads where cost optimization through EC2 pricing models is beneficial
  • Specialized compute requirements needing specific EC2 instance types (Graviton4, network-optimized instances)
  • High-throughput scenarios where concurrent execution improves performance
  • Workloads requiring EC2 flexibility while maintaining serverless operational simplicity

Code Changes Required

Migrating to Lambda Managed Instances requires two simple changes:

1. Use LambdaManagedRuntime instead of LambdaRuntime
// Before (standard Lambda)
let runtime = LambdaRuntime {
    (event: HelloRequest, context: LambdaContext) in
    HelloResponse(greetings: "Hello \(event.name)!")
}

// After (Lambda Managed Instances)
let runtime = LambdaManagedRuntime {
    (event: HelloRequest, context: LambdaContext) in
    HelloResponse(greetings: "Hello \(event.name)!")
}

try await runtime.run()
2. Ensure Handlers are Sendable

Because Lambda Managed Instances support concurrent invocations, your handler functions and structs must conform to Sendable:

struct MyHandler: LambdaWithBackgroundProcessingHandler, Sendable {
    typealias Event = MyRequest
    typealias Output = MyResponse
    
    func handle(
        _ event: Event,
        outputWriter: some LambdaResponseWriter<Output>,
        context: LambdaContext
    ) async throws {
        try await outputWriter.write(MyResponse(message: "Processed"))
    }
}

let adapter = LambdaCodableAdapter(handler: MyHandler())
let runtime = LambdaManagedRuntime(handler: adapter)
try await runtime.run()

For simple data structures, the Swift compiler automatically infers Sendable conformance.

Implementation Details

  • Thread-safe execution: The runtime detects the configured concurrency level (AWS_LAMBDA_MAX_CONCURRENCY) and launches the appropriate number of Runtime Interface Clients (RICs) to handle concurrent requests
  • Backward compatibility: When AWS_LAMBDA_MAX_CONCURRENCY is 1 or unset, the runtime maintains single-threaded behavior for optimal performance on traditional Lambda deployments
  • No breaking changes: The public API remains unchanged; existing Lambda functions continue to work without modification

This is a purely additive feature with no breaking changes—existing Lambda functions continue to work without modification. The managed instances support is implemented behind a Swift package trait (ManagedRuntimeSupport) that's enabled by default. If you're concerned about binary size and don't need managed instances support, you can disable this trait in your Package.swift:

dependencies: [
    .package(
        url: "https://github.com/awslabs/swift-aws-lambda-runtime.git",
        from: "2.0.0",
        traits: [
            // Keep other default traits but exclude ManagedRuntimeSupport
            "FoundationJSONSupport",
            "ServiceLifecycleSupport",
            "LocalServerSupport"
        ]
    ),
],
targets: [
    .executableTarget(
        name: "MyLambda",
        dependencies: [
            .product(name: "AWSLambdaRuntime", package: "swift-aws-lambda-runtime"),
        ]
    ),
]

Examples

The release includes three comprehensive examples in Examples/ManagedInstances/:

  • HelloJSON: JSON input/output with structured data types
  • Streaming: Response streaming capabilities with concurrent execution
  • BackgroundTasks: Long-running background processing after response

See the ManagedInstances example README for deployment instructions using AWS SAM.

Prerequisites

Before deploying to Lambda Managed Instances:

  1. Create a Lambda Managed Instances capacity provider
  2. Configure your deployment to reference the capacity provider ARN

Additional Resources

What's Changed

SemVer Minor
  • Add support for Lambda Managed Instances without changing the public API [CORE] by @​sebsto in #​629
  • Add support for Lambda Managed Instances without changing the public API [Convenience + Example] by @​sebsto in #​623

Full Changelog: awslabs/swift-aws-lambda-runtime@2.5.3...2.6.0

v2.5.3

Compare Source

This patch release fixes two critical race conditions that could cause crashes in production and test environments:

Bug Fixes

  • Fixed race condition crash in LambdaRuntimeClient channel lifecycle (#​632)
  • Fixed race condition in Lambda+LocalServer causing NIOAsyncWriter fatal error (#​636)

These fixes improve the stability and reliability of the Swift AWS Lambda Runtime, particularly in high-concurrency scenarios.

What's Changed

SemVer Patch

Full Changelog: awslabs/swift-aws-lambda-runtime@2.5.2...2.5.3

v2.5.2

Compare Source

Local server test hangs: Fixed race conditions in Pool cancellation logic that caused test suite to hang ~10% of the time

  • Individual task cancellations no longer incorrectly cancel all waiting tasks
  • Server shutdown now properly cleans up waiting continuations
  • Improves reliability of local testing and concurrent invocation handling

Impact: Test suite now runs consistently without hangs. Local server testing is more reliable.

What's Changed

SemVer Patch
Other Changes

Full Changelog: awslabs/swift-aws-lambda-runtime@2.5.1...2.5.2

v2.5.1

Compare Source

This patch sharpens the developer experience: the payload trace limit is lifted, so you get 6 Mb traces when inspecting Lambda events and responses. In practice, this means clearer insight into real-world payloads, faster root-cause analysis, and fewer blind spots when debugging.

What's Changed

SemVer Patch
  • Lift up the trace limit on payload to make it actually useful when debugging by @​sebsto in #​625

Full Changelog: awslabs/swift-aws-lambda-runtime@2.5.0...2.5.1

v2.5.0

Compare Source

This release relaxes Sendable constraint on StreamingClosureHandler.

Key changes:

  • Removed & Sendable conformance from StreamingClosureHandler struct
  • Removed @Sendable annotation from the closure type used in the handler

What's Changed

SemVer Minor
Other Changes

Full Changelog: awslabs/swift-aws-lambda-runtime@2.4.1...2.5.0

v2.4.1

Compare Source

A dot release that mostly fixes the compilation error introduced by a breaking API change in swift Log.

Beside that, here are some newsworthy changes

  • Some improvements in the test suite and the CI
  • A new example for streaming functions + API Gateway

What's Changed

SemVer Minor
Other Changes

Full Changelog: awslabs/swift-aws-lambda-runtime@2.4.0...2.4.1

v2.4.0

Compare Source

This release adds support for AWS Lambda tenant isolation mode.
https://aws.amazon.com/blogs/aws/streamlined-multi-tenant-application-development-with-tenant-isolation-mode-in-aws-lambda/

let runtime = LambdaRuntime {
    (event: APIGatewayRequest, context: LambdaContext) -> APIGatewayResponse in

    // Extract tenant ID from context
    guard let tenantID = context.tenantID else {
        return APIGatewayResponse(statusCode: .badRequest, body: "No Tenant ID provided")
    }

...

See Examples/MultiTenant for a full example.

What's Changed

SemVer Minor
Other Changes

Full Changelog: awslabs/swift-aws-lambda-runtime@2.3.1...2.4.0

swift-server/swift-aws-lambda-events (swift-server/swift-aws-lambda-events)

v0.5.0

Compare Source

Main Changes

All changes

New Contributors

Full Changelog: awslabs/swift-aws-lambda-events@0.4.0...0.5.0

Configuration

📅 Schedule: (in timezone Pacific/Auckland)

  • Branch creation
    • "before 9am on monday"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot added the dependencies Pull requests that update a dependency file label Jul 9, 2026
@renovate
renovate Bot merged commit e16a9fb into main Jul 9, 2026
4 checks passed
@renovate
renovate Bot deleted the renovate/swift-aws-lambda-runtime branch July 9, 2026 03:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants