This PR has been reworked. Instead of silently switching the default
base image based on Swift version, we now:
1. **Keep Amazon Linux 2 as the default** base Docker image for the
packager plugin
2. **Add a prominent deprecation warning** when AL2 is used (either via
Docker or natively), informing developers that AL2 reaches End of Life
on June 30, 2026
3. **Migrate all examples** (READMEs, SAM templates, scripts) to build
and deploy on Amazon Linux 2023 (`provided.al2023` runtime +
`--base-docker-image swift:amazonlinux2023`)
4. **Update documentation** (readme, quick-setup) with migration notes
The warning includes the `--base-docker-image swift:6.3-amazonlinux2023`
flag and reminds developers to use the `provided.al2023` runtime when
deploying.
After June 30, 2026, the default will switch to AL2023.
---
<details>
<summary>Original PR description (superseded)</summary>
~~Now that Docker Hub has official Swift images based on Amazon Linux
2023 (starting with 6.3), the packager plugin picks the right base image
automatically depending on the Swift version:~~
~~- Swift 6.3 and later: `swift:<version>-amazonlinux2023`~~
~~- Earlier versions: `swift:<version>-amazonlinux2` (unchanged
behavior)~~
~~- No version specified (latest): defaults to `amazonlinux2023`~~
~~When only a major version is provided (e.g. `--swift-version 6`
without a minor), we conservatively treat it as 6.0 and use Amazon Linux
2, since we can't be sure it's 6.3+.~~
~~Also added a verbose log line showing the resolved Swift version,
Amazon Linux version, and final base image to help with debugging.~~
~~The `--base-docker-image` flag still overrides everything as before.~~
</details>
---------
Co-authored-by: Sébastien Stormacq <stormacq@amazon.lu>
Apply recommendations in code and documentation
- [CI] restrict permissions to read-all instead of the default write-all
- All examples README.md : add a note about Lambda functions
configuration with improved security and scalability changes for
production environment
- Swift docc documentation: add a note about Lambda functions
configuration with improved security and scalability changes for
production environment
---------
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
Revert streaming codable handler change and propose it as an example
instead of an handler API.
**Motivation:**
I made a mistake when submitting this PR
https://github.com/swift-server/swift-aws-lambda-runtime/pull/532
It provides a Streaming+Codable handler that conveniently allows
developers to write handlers with `Codable` events for streaming
functions.
This is a mistake for three reasons:
- This is the only handler that assumes a Lamba Event structure as
input. I added a minimal `FunctionUrlRequest` and `FunctionURLResponse`
to avoid importing the AWS Lambda Events library. It is the first
handler to be event-specific. I don't think the runtime should introduce
event specific code.
- The handler only works when Lambda functions are exposed through
Function URLs. Streaming functions can also be invoke by API or CLI.
- The handler hides `FunctionURLRequest` details (HTTP headers, query
parameters, etc.) from developers
Developers were unaware they were trading flexibility for convenience
The lack of clear documentation about these limitations led to incorrect
usage patterns and frustrated developers who needed full request control
or were using other invocation methods.
**Modifications:**
- Removed the Streaming+Codable API from the library
- Moved the Streaming+Codable code to an example
- Added prominent warning section in the example README explaining the
limitations
- Clarified when to use Streaming+Codable vs ByteBuffer approaches
- Added decision rule framework to help developers choose the right
approach
**Result:**
The only API provided by the library to use Streaming Lambda functions
is exposing the raw `ByteBuffer` as input, there is no more `Codable`
handler for Streaming functions available in the API. I kept the
`Streaming+Codable` code an example.
After this change, developers have clear guidance on when to use each
streaming approach:
- Use streaming codable for Function URL + JSON payload + no request
details needed
- Use ByteBuffer StreamingLambdaHandler for full control, other
invocation methods, or request metadata access
This prevents misuse of the API and sets proper expectations about the
handler's capabilities and limitations, leading to better developer
experience and fewer integration issues.
Sébastien Stormacq