soup-dev/scaleway-serverless-python - Codeberg.org
This website requires JavaScript.
soup-dev/scaleway-serverless-python
Watch
Star
Fork
You've already forked scaleway-serverless-python
Code
Issues
Pull requests
Activity
No description
2 commits
1 branch
0 tags
47 KiB
Shell
45.8%
HCL
42.5%
Python
11.7%
main
Find a file
HTTPS
Download ZIP<br>Download TAR.GZ<br>Download BUNDLE
Open with VS Code
Open with VSCodium
Open with Intellij IDEA
mirch
251056d23c
All checks were successful
ci/woodpecker/push/cd Pipeline was successful
Details
Add instructions
2026-07-06 20:44:10 +02:00
.woodpecker
A new start
2026-07-06 21:14:00 +03:00
infrastructure
A new start
2026-07-06 21:14:00 +03:00
scripts
A new start
2026-07-06 21:14:00 +03:00
src
A new start
2026-07-06 21:14:00 +03:00
.gitignore
A new start
2026-07-06 21:14:00 +03:00
README.md
Add instructions
2026-07-06 20:44:10 +02:00
README.md
Serverless Python functions on Scaleway
This repo contains a basic project that deploys a Python serverless function to Scaleway. It uses tofu to define the infrastructure, which is then deployed to Scaleway through a Woodpecker agent.
The problem
While deploying simple functions to Scaleway is quite easy, including any packages that depend on platform-specific wheels can become a headache; the Scaleway log messages are not very helpful, either.
The example function in this project used pydantic as a requirements, which in turn requires pydantic-core. Since pydantic-core represents a platform-specific Rust binary, it will raise errors if the build platform is different than the target one (in this case, the Woodpecker agent OS vs the Scaleway function OS).
The solution
In order to install the right binary, this repo uses a build script that install all the requirements, then looks at the pydantic-core version that was installed and changes it to the binary for musllinux_1_1_x86_64.
If any of the packages you install contain platform-specific wheels, the same process must be repeated for each wheel.
Deployment and test
The project can be deployed through Woodpecker (or similar CI tools), or locally (with the right credentials applied) by running:
./scripts/build.sh<br>cd infrastructure<br>tofu init<br>tofu apply<br>A serverless function called greeting-handler will be created, which can be called using its function domain endpoint:
curl --location 'https://{function_id}-greeting-handler.functions.fnc.fr-par.scw.cloud' \<br>--header 'Content-Type: application/json' \<br>--data '{<br>"name": "soupdev"<br>}'
{"message":"Hello, soupdev!"}