Runtimes

IBM Cloud® Functions is deprecated. Existing Functions entities such as actions, triggers, or sequences will continue to run, but as of 28 December 2023, you can’t create new Functions entities. Existing Functions entities are supported until October 2024. Any Functions entities that still exist on that date will be deleted. For more information, see Deprecation overview.

Your apps can be coded and executed in programming languages such as JavaScript or Python. Many runtimes are available by default with IBM Cloud® Functions.

Available images and runtimes

These runtimes (kinds) are available:

Table 1. Supported runtimes
Language	Kind identifier
Node.js	`nodejs:20` (default)
Python	`python:3.11` (default)
PHP	`php:8.1` (default)
Go	`go:1.21` (default)
Java	`java (JDK 8)` (default)

Other languages are supported by using Docker actions.

Runtimes are updated regularly. These updates include security fixes and minor version updates (bug fixes) to the runtime packages. Minor version updates might introduce breaks in compatibility with earlier versions. Runtime updates might impact your actions.

A runtime might also be deprecated, which means that certain runtime components are no longer supported. A deprecated runtime is still available for a certain time after deprecation and your actions continue to be executed as normal. However, you cannot create or update an action with a deprecated runtime from the console. The console marks actions that use a deprecated runtime. Note that you can create and update actions with a deprecated runtime from the CLI, however, it is highly recommended not to use deprecated runtimes.

After a runtime is deprecated, it becomes disabled. The timeframe between deprecated and disabled is not fixed and can vary from a few months to a few years. After a runtime is disabled, actions that use this runtime fail with the error 400, bad request. An action that uses a disabled runtime can still be read and deleted.

Migrate actions that are running on a deprecated or disabled runtime to a different runtime version by updating it. To update the runtime, see changing action runtime.

These runtimes (kinds) are deprecated:

go:1.19 (deprecated)
nodejs:12 (deprecated)
nodejs:16 (deprecated)
python:3.7 (deprecated)
python:3.9 (deprecated)

These runtimes (kinds) are disabled:

ballerina:0.990 (disabled)
dotnet:2.2 (disabled)
go:1.11 (disabled)
go:1.15 (disabled)
go:1.17 (disabled)
nodejs (disabled)
nodejs:6 (disabled)
nodejs:8 (disabled)
nodejs:10 (disabled)
php:7.1 (disabled)
php:7.2 (disabled)
php:7.3 (disabled)
php:7.4 (disabled)
python (disabled)
python:2 (disabled)
python:3.6 (disabled)
ruby:2.5 (disabled)
ruby:2.6 (disabled)
swift (disabled)
swift:3 (disabled)
swift:3.1.1 (disabled)
swift:4.1 (disabled)
swift:4.2 (disabled)

For more information about supported and disabled runtimes, see Available images and runtimes per region.

JavaScript runtimes

By default, all Node.js actions are executed in a version 20 environment.

Node.js version 16 is deprecated and is planned to be removed soon. To continue running your actions, you must update any Node.js version 12 actions to a higher runtime version. For more information, see the Node.js release schedule.

Node.js version 12 is deprecated and is planned to be removed soon. To continue running your actions, you must update any Node.js version 12 actions to a higher runtime version. For more information, see the Node.js release schedule.

Table 1. Node.js versions
Kind	Node.js version	Description	Change log
`nodejs:20`	20.x	By default, all Node.js actions are executed in a version 20 environment.	`CHANGELOG.md`.
`nodejs:16`	16.x	Deprecated	`CHANGELOG.md`.
`nodejs:12`	12.x	Deprecated	`CHANGELOG.md`.
`nodejs:10`	10.x	Disabled	`CHANGELOG.md`.
`nodejs:8`	8.x	Disabled	`CHANGELOG.md`.

Migrating from Node.js 16 to Node.js 20

Table 2. Migrating details from Node.js 16 to Node.js 20
Package	Details
`cloudant`	The `@ibm-cloud/cloudant` SDK package in the `nodejs:20` runtime has been upgraded from to `0.5.5` and includes interface changes. For more information about the `@ibm-cloud/cloudant` SDK look at the IBM Cloudant Docs.
`request-promise`	The `request-promise` package has been removed as it is deprecated. If you still require this module, consider packaging `request-promise` with your action as described in Packaging JavaScript code as NPM files.
`mongodb`	The `mongodb` package in the `nodejs:20` runtime is at version v5.x. Major version changes can introduce incompatibilities, which might cause your action to fail. If your action uses an earlier version of this package, consider migrating to the current version. For more information about migrating to the current version of `mongodb`, see the Upgrade Driver Versions for MongoDB. If you can't migrate, consider packaging the older version of `mongodb` package with your action as described in Packaging JavaScript code as NPM files.
`elasticsearch`	The `elasticsearch` SDK package in the `nodejs:16` runtime is deprecated and has been replaced with `@elastic/elasticsearch` in `nodejs:20`. This is a major change and will cause incompatibilities, which might cause your action to fail. If your action uses `elasticsearch` consider migrating to `@elastic/elasticsearch`. For more information about migrating to `@elastic/elasticsearch`, see Migrating to @elastic/elasticsearch. If you can't migrate, consider packaging `@elastic/elasticsearch` with your action as described in Packaging JavaScript code as NPM files. For more information about the `@elastic/elasticsearch` SDK look at the Official Homepage.

For more information about migrating to Node.js:20, see (Details on GitHub).

Migrating from Node.js 12 to Node.js 16

Table 2. Migrating details from Node.js 12 to Node.js 16
Package	Details
`cloudant`	The `@cloudant/cloudant` SDK package in the `nodejs:12` runtime is deprecated and has been replaced with `@ibm-cloud/cloudant` in `nodejs:16`. This is a major change and will cause incompatibilities, which might cause your action to fail. If your action uses `@cloudant/cloudant` consider migrating to `@ibm-cloud/cloudant`. For more information about migrating to `ibm-watson v6.x`, see Migrating to the cloudant-node-sdk. If you can't migrate, consider packaging `@cloudant/cloudant` with your action as described in Packaging JavaScript code as NPM files. For more information about the `@ibm-cloud/cloudant` SDK look at the IBM Cloudant Docs.
`redis`	The `redis` package in the `nodejs:16` runtime is at version v4.x. Major version changes can introduce incompatibilities, which might cause your action to fail. If your action uses an earlier version of this package, consider migrating to the current version. For more information about migrating to `redis v4`, see v3 to v4 Migration Guide. If you can't migrate, consider packaging the older version of `redis` package with your action as described in Packaging JavaScript code as NPM files.
`uuid`	The `uuid` package in the `nodejs:16` runtime is at version v8.x. Major version changes can introduce incompatibilities, which might cause your action to fail. If your action uses an earlier version of this package, consider migrating to the current version. For more information about migrating to the current version pf `uuid`, see Upgrading From uuid@3.x. If you can't migrate, consider packaging the older version of `redis` package with your action as described in Packaging JavaScript code as NPM files.

For more information about migrating to Node.js:12, see (Details on GitHub).

Migrating from Node.js 10 to Node.js 12

Table 2. Migrating details from Node.js 10 to Node.js 12
Package	Details
`ibm-watson`	The current `ibm-watson` SDK package in the `nodejs:12` runtime is at version v6.x. Major version changes can introduce incompatibilities, which might cause your action to fail. If your action uses an earlier version of this package, consider migrating to the current version. If you can't migrate, consider packaging the older version of `ibm-watson` package with your action as described in Packaging JavaScript code as NPM files.
`ibmiotf`	The `ibmiotf` package is renamed to `@wiotp/sdk`. For more information, see IBM Watson IoT Platform JavaScript SDK.
`request`	The `request` package is deprecated and therefore not available in this runtime. You can consider `axios`, `bent`, `got`, or `needle` as an alternative.

For more information about migrating to Node.js:12, see (Details on GitHub).

Migrating from Node.js 8 to Node.js 10

Table 3. Details for migrating from Node.js 8 to Node.js 10
Package	Details
`cloudant`	The `cloudant` NPM package is not available in `nodejs:10`. The package is deprecated. You need to use the official NPM package @cloudant/cloudant v3.0.0 when you import the Node.js module (that is, `require('@cloudant/cloudant')`) also v3.x only returns Promises.
`cradle`	The `cradle` NPM package is not available in `nodejs:10`.
`watson-developer-cloud`	The `watson-developer-cloud` NPM package available in `nodejs:10` is version 4.x. This version includes support for Promises. A list of the changes that are made is documented. Note that this package is deprecated and is no longer supported. This package does not receive updates and is planned to be removed in the future. Move your action to the `ibm-watson` package.
`ibm-watson`	The `ibm-watson` package available in `nodejs:10` is version 4.x. This package is the successor of the `watson-developer-cloud` package. Upgrade your action code to use this new package, since the former does not receive updates. This package includes support for promises.
`ibmiotf`	The package `ibmiotf` has been renamed by the maintainers to `@wiotp/sdk`. Make sure to update your action code to the new package. See `@wiotp/sdk` for all changes. The package `ibmiotf` does not receive further updates and is planned to be removed from this runtime in the future.

For more information about migrating to Node.js:10, see (Details on GitHub).

Node.js packages

For information about Node.js 20 packages, see (Details on GitHub).

For information about Node.js 16 packages, see (Details on GitHub).

Table 1. Node.js 12 packages.
Node.js 12 packages	Description
`@cloudant/cloudant`	This library is the official Cloudant library for Node.js.
`@ibm-functions/iam-token-manager`	This package is an IAM access token manager library for Node.js.
`@sendgrid/mail`	Provides email support via the SendGrid API.
`@wiotp/sdk`	IBM Watson IoT Platform JavaScript SDK.
`amqplib`	A library for making AMQP 0-9-1 clients for Node.js.
`apn`	A Node.js module for interfacing with the Apple Push Notification service.
`async`	Provides functions for working with asynchronous functions.
`axios`	Promise-based HTTP client for the browser and Node.js.
`bent`	Functional HTTP client for Node.js with `async/await`.
`bodyparser`	Parse incoming request bodies in a middleware before your handlers, available under the req.body property.
`btoa`	A port of the browser's `btoa` function.
`bufferutil`	`bufferutil` is what makes `ws` fast.
`canvas`	A Cairo-backed Canvas implementation for Node.js.
`cassandra-driver`	DataStax Node.js Driver for Apache Cassandra.
`commander`	The complete solution for Node.js command-line interfaces.
`composeaddresstranslator`	Address translator from Compose UI or API for Scylla databases.
`consul`	A client for Consul, involving service discovery and configuration.
`cookie-parser`	Parse Cookie header and populate req.cookies with an object keyed by the cookie names.
`core-js`	Modular standard library for JavaScript.
`elasticsearch`	The official low-level `Elasticsearch` client for Node.js.
`errorhandler`	Development-only error handler middleware.
`etcd3`	A high-quality, production-ready client for the Protocol Buffer-based etcdv3 API.
`express`	A fast, minimalist web framework for node.
`express-session`	A server-side session data storing module.
`formidable`	A Node.js module for parsing form data, especially file uploads.
`glob`	Match files by using the patterns that the shell uses, like stars and stuff.
`gm`	GraphicsMagick and ImageMagick for Node.
`got`	Human-friendly and powerful HTTP request library for Node.js.
`ibm-cos-sdk`	IBM Cloud® Object Storage SDK for Node.js.
`ibm_db`	An asynchronous/synchronous interface for Node.js to IBM DB2 and IBM Informix.
`ibm-watson`	A Node.js client library to use the Watson APIs.
`iconv-lite`	Pure JS character encoding conversion.
`jest`	Delightful JavaScript Testing.
`jsdom`	`jsdom` is a pure-JavaScript implementation of many web standards, notably the `WHATWG` DOM and HTML Standards.
`jsforce`	Salesforce API Library for JavaScript applications.
`jsonwebtoken`	An implementation of JSON Web Tokens.
`lodash`	The `Lodash` library that is exported as Node.js modules.
`log4js`	This package is a conversion of the `log4js` framework to work with node.
`marked`	A full-featured markdown parser and compiler, which is written in JavaScript. Built for speed.
`merge`	Merge multiple objects into one, optionally creating a new cloned object.
`moment`	A lightweight JavaScript date library for parsing, validating, manipulating, and formatting dates.
`mongodb`	The official MongoDB driver for Node.js.
`mustache`	mustache.js is an implementation of the mustache template system in JavaScript.
`mysql`	This package is a Node.js driver for `mysql`.
`nano`	Minimalistic `couchdb` driver for Node.js.
`needle`	The leanest and most handsome HTTP client in the `Nodelands`.
`nodemailer`	Send emails from Node.js – easy as cake!
`oauth2-server`	Complete, compliant, and well-tested module for implementing an OAuth2 Server/Provider with express in Node.js.
`openwhisk`	JavaScript client library for the OpenWhisk platform. Provides a wrapper around the OpenWhisk APIs.
`path-to-regex`	Turn a path string such as `/user/:name` into a regular expression, which can then be used to match against URL paths.
`pg`	Non-blocking PostgreSQL client for Node.js. Pure JavaScript and optional native `libpq` bindings.
`process`	`require('process');`, just like any other module.
`pug`	Implements the Pug templating language.
`redis`	This package is a complete and feature rich Redis client for Node.js.
`request-promise`	The simplified HTTP request client 'request' with Promise support. Powered by Bluebird.
`rimraf`	The UNIX command `rm -rf` for node.
`semver`	Semantic Versioning for Node.js.
`serialize-error`	Serialize an error into a plain object.
`serve-favicon`	Node.js middleware for serving a `favicon`.
`socket.io`	`Socket.io` enables real-time bidirectional event-based communication.
`socket.io-client`	Realtime application framework for `socket.io`.
`superagent`	`SuperAgent` is a small progressive client-side HTTP request library, and Node.js module with the same API, sporting many high-level HTTP client features.
`swagger-tools`	Package that provides various tools for integrating and interacting with Swagger.
`tmp`	A simple temporary file and directory creator for Node.js.
`ts-jest`	A TypeScript preprocessor with source map support for Jest that enables you use Jest to test projects written in TypeScript.
`twilio`	A wrapper for the Twilio API, related to voice, video, and messaging.
`underscore`	Underscore.js is a utility-belt library for JavaScript that supports the usual functional suspects (each, map, reduce, filter, and so on) without extending any core JavaScript objects.
`url-pattern`	Parse URLs for path parameters more easily than from using a regex string matcher.
`utf-8-validate`	Check whether a buffer contains valid `UTF-8` encoded text.
`uuid`	Simple, fast generation of `RFC4122 UUIDS`.
`validator`	A library of string validators and sanitizers.
`vcap_services`	Parse and return service credentials from `VCAP_SERVICES` environment variable that IBM Cloud provides.
`when`	`when.js` is a rock solid, battle-tested, and Promises/A+, and when() implementation, including a complete ES6 Promise shim.
`winston`	A multi-transport `async` logging library for Node.js. "`CHILL WINSTON! ... I put it in the logs.`"
`ws`	`ws` is a simple to use, blazing fast, and thoroughly tested WebSocket client and server implementation.
`xlsx`	Parser and writer for various spreadsheet formats.
`xml2js`	Simple XML to JavaScript object converter. It supports bidirectional conversion.
`xmlhttprequest`	`node-XMLHttpRequest` is a wrapper for the built-in HTTP client to emulate the browser `XMLHttpRequest` object.
`yauzl`	Yet another extract library for node. For zipping.
`yazl`	Yet another extract library for node. For zipping.

For more information about Node.js 12 packages, see (Details on GitHub).

Python runtimes

By default, all Python actions are executed in a Python version 3.11 environment.

Table 4. Python versions
Kind	Python version	Description	Change log
`python:3.11`	3.11.x	By default, all Python actions are executed in a Python version 3.11.x environment (Debian Buster based) unless you specify the `--kind` flag when you create or update an action. To explicitly use this runtime, specify the CLI parameter `--kind python:3.11` when you create or update an action. The runtime contains SDK packages for IBM Cloud services available for use by Python actions, in addition to the Python 3.11 standard libraries.	`CHANGELOG.md`.
`python:3.9`	3.9.x	Python actions are executed in a Python version 3.11.x environment (Debian Buster based) unless you specify the `--kind` flag when you create or update an action. To explicitly use this runtime, specify the CLI parameter `--kind python:3.9` when you create or update an action. The runtime contains SDK packages for IBM Cloud services available for use by Python actions, in addition to the Python 3.9 standard libraries.	`CHANGELOG.md`.
`python:3.7`	3.7.x	Python actions are executed in a Python version 3.11.x environment (Debian Stretch based) unless you specify the `--kind` flag when you create or update an action. To explicitly use this runtime, specify the CLI parameter `--kind python:3.7` when you create or update an action. The runtime contains SDK packages for IBM Cloud services available for use by Python actions, in addition to the Python 3.7 standard libraries.	`CHANGELOG.md`.
	3.6	Python 3.6 reached `end of support` on 2021/12/23. See end of life Python Releases.
	2.7	Python 2.7 reached `end of support` on 2020/01/01. See the Active Python Releases.

Migrating from Python 3.7 to Python 3.9, Python 3.11

Table 2. Migrating details from Python 3.7 to Python 3.9
Package	Details
`ibmcloudant`	The `cloudant` sdk has moved to the new `ibmcloudant` sdk. It includes a number of breaking changes. See migration guide for more information.
`ibm-watson`	The `watson-developer-cloud` sdk has renamed to the new `ibm-watson` sdk and includes breaking changes. See pypi ibm-watson and github ibm-watson for more information.

For more information about migrating to python:3.9, see (Details on GitHub).

Python packages

Ensure that your action uses only the packages that are mentioned in the following table. \n While other Python packages might be part of the runtime, they are included only as indirect dependencies of the other listed packages. These unlisted packages are candidates to be removed as soon as they are not required by the referring package.

Table 1. Python 3.11 packages
Python 3.11 packages
`beautifulsoup4`
`botocore`
`cassandra-driver`
`ibmcloudant`
`elasticsearch`
`etcd3`
`flask`
`gevent`
`httplib2`
`ibm-cos-sdk`
`ibm_db`
`ibmcloudsql`
`kafka_python`
`lxml`
`numpy`
`pandas`
`pika`
`Pillow`
`psycopg2`
`PyJWT`
`pymongo`
`python-dateutil`
`redis`
`requests`
`scikit-learn`
`scipy`
`scrapy`
`simplejson`
`tornado`
`twisted`
`virtualenv`
`ibm-watson`

Table 2. Python 3.9 packages
Python 3.9 packages
`beautifulsoup4`
`botocore`
`cassandra-driver`
`ibmcloudant`
`elasticsearch`
`etcd3`
`flask`
`gevent`
`httplib2`
`ibm-cos-sdk`
`ibm_db`
`ibmcloudsql`
`kafka_python`
`lxml`
`numpy`
`pandas`
`pika`
`Pillow`
`psycopg2`
`PyJWT`
`pymongo`
`python-dateutil`
`redis`
`requests`
`scikit-learn`
`scipy`
`scrapy`
`simplejson`
`tornado`
`twisted`
`virtualenv`
`ibm-watson`

Table 3. Python 3.7 packages
Python 3.7 packages
`beautifulsoup4`
`botocore`
`cassandra-driver`
`cloudant`
`elasticsearch`
`etcd3`
`flask`
`gevent`
`httplib2`
`ibm-cos-sdk`
`ibm_db`
`ibmcloudsql`
`kafka_python`
`lxml`
`numpy`
`pandas`
`pika`
`Pillow`
`psycopg2`
`PyJWT`
`pymongo`
`python-dateutil`
`redis`
`requests`
`scikit-learn`
`scipy`
`scrapy`
`simplejson`
`tornado`
`twisted`
`virtualenv`
`watson-developer-cloud`

Table 4. Python 3.6 packages
Python 3.6 packages
`cassandra-driver`
`cloudant`
`elasticsearch`
`beautifulsoup4`
`flask`
`gevent`
`httplib2`
`ibm-cos-sdk`
`ibm_db`
`ibmcloudsql`
`kafka_python`
`lxml`
`numpy`
`pandas`
`pika`
`Pillow`
`psycopg2`
`pymongo`
`python-dateutil`
`redis`
`requests`
`scikit-learn`
`scipy`
`scrapy`
`simplejson`
`twisted`
`virtualenv`
`watson-developer-cloud`

For more information about Python 3.11 packages, see (Details on GitHub).

For more information about Python 3.9 packages, see (Details on GitHub).

For more information about Python 3.7 packages, see (Details on GitHub).

For more information about Python 3.6 packages, see (Details on GitHub).

PHP runtime

By default, all PHP actions are executed in a version 8.1 environment.

For more information about the php:8.1 runtime, see (Details on GitHub).

The following PHP extensions are available in addition to the standard ones.

bcmath
curl
gd
intl
mbstring
mongodb
mysqli
pdo_mysql
pdo_pgsql
pdo_sqlite
soap
zip

Ensure that your action uses only the modules that are mentioned in the following table. \n While other PHP modules might be part of the runtime, they are included only as indirect dependencies of the other listed modules. These unlisted modules are candidates to be removed as soon as they are not required by the referring modules.

Docker runtime

Docker actions run a user-supplied executable in a Docker container. You can include any compilation steps or dependencies by modifying your Dockerfile. You can specify a Docker image to use with your action code by specifying the --docker flag when you run the action create command. When you create an action that uses a Docker image, your app runs in the public Docker image that you specify during action creation.

Cloud Functions provides base images on Docker hub. You can use these images as-is when you create actions, or you can use them as a base image when you write your Dockerfile. You can see a list of the available runtimes images in the Available images and runtimes section.

Cloud Functions actions can be created by using public images on from Docker Hub.

Docker skeleton

You can use the openwhisk/dockerskeleton image to deploy your action. You can use the --native argument as shorthand for --docker openwhisk/dockerskeleton. By using this argument, you can create and deploy an executable that runs inside the standard Docker action SDK.

For more information, see Creating actions from binaries.

More runtime support

Go

By default, all Go actions are executed in a version 1.19 environment. Go Version 1.11, 1.15 and 1.17 are deprecated. When migrating from Go:1.11 to Go:1.17 and higher:

Go:1.17 uses Go Modules.
File containing the entry function (e.g main.go Main) needs be placed in root, no "main" directory is supported.

For more information about the go runtimes, see (Details on GitHub).

For more information about writing go actions, see Preparing Go apps.

Java

By default, all Java actions are executed in a version 8 environment.

For more information about the java:8 runtime, see (Details on GitHub).

.NET Core (deprecated)

The .NET core runtime is deprecated. There is no replacement. Instead, you must migrate to a different runtime.

Available images and runtimes per region

To view the available runtimes for IBM Cloud Functions in each region. The following links return a JSON response. The runtimes section of the response contains the set of available runtimes. The image section contains the name of the runtime image on Docker Hub and the tag that is used.

The following examples point to the images ibmfunctions/action-nodejs-v12 and openwhisk/java8action on hub.docker.com. The tags can be version numbers such as 1.1.1 or the short form of a Git commit hash, like a231007.

Example image fields.

image:   "ibmfunctions/action-nodejs-v12:1.1.1"

image:   "openwhisk/java8action:a231007"

This JSON response shows the supported and the disabled runtimes. Disabled runtimes are marked with deprecated=true. Deprecated runtimes are not shown in this response. The deprecated flag that is returned in the response does not correspond to the deprecated runtimes as mentioned in Available images and runtimes.

Deprecated runtimes are not marked as such in this response until the runtime is finally disabled. Deprecated runtimes are only marked as such in the console and in this documentation (Available images and runtimes).

When you troubleshoot a failing action (400, bad request) to identify whether a disabled runtime is used, check for deprecated=true in the query response. Actions that use a disabled runtime can be only read or deleted. You cannot run such an action.

To update the runtime of this action to a supported one, see changing action runtime.