Function runtimes
Code Engine includes managed runtimes that you can use for your functions.
Managed runtimes include Node.js and Python versions and specific CPU and memory combinations. These runtimes are optimized for fast startup. These runtimes are pre-warmed, which avoids the pulling of container images and starting containers and processes. Your code is injected into an already running container.
Need to deploy a container image? See Working with apps or Working with jobs and job runs. Not sure what type of Code Engine workload to create? See Planning for Code Engine.
Supported managed runtimes for functions on Code Engine
The following runtimes are supported as managed runtimes.
- Node.js 18 and Node.js 20
- Python 3.11
Supported CPU and memory combinations for functions
See the following list for valid combinations of CPU and memory for functions.
- 0.25 vCPU and 1 GB memory
- 0.5 vCPU and 2 GB memory
- 1 vCPU and 4 GB memory (Default)
For memory and CPU information, see Supported memory and CPU combinations.
Runtime support lifecycle
The support lifecycle of managed runtimes for Code Engine functions depends on the official support cycles of the programming language release on which they are based. If the runtime that your function uses reaches its end of life, your function stops working. Before end of life is a deprecation period (typically six months), when the runtime continues to receive security updates during user migration to the new runtime release. The following table lists the deprecation and end of life dates:
| Runtime | Deprecation | End of life |
|---|---|---|
| Node.js 18 | 1 October 2024 | 30 April 2025 |
| Node.js 20 | 1 November 2025 | 30 April 2026 |
| Python 3.11 | 1 May 2027 | 30 September 2027 |
Upgrading a function to a new runtime release
New runtime releases can contain breaking API changes and functions might require code changes, which must be tested. Use the Code Engine ibmcloud ce function update --runtime CLI command to update your existing functions to use
a new runtime version. Doing so Immediately causes the function to run with the new (selected) runtime release as the base (=in-place update). Therefore, do not use any in-place updates for production code. Create a test function during the
migration phase.
Updating production code depends on whether it is acceptable that the function's URL is changed or if the URL must be kept:
-
If function URL endpoint changes are acceptable:
- create a new function based on the same source code (or code bundle) as the original function, by using the new runtime release.
- make sure that the new function works as expected. If it does not, adapt the source code and rebuild the function.
- use the new function URL and remove the previous version.
-
If the original function URL endpoint must be kept:
- create a new function (as a test function) based on the same source code (or code bundle) as the original function, by using the new runtime release
- make sure that the test function works as expected. If it does not, adapt the code and rebuild the test function.
- update the original function to use the new runtime release and the adapted source code.