Update docs for new runtime API (nodejs26, python314)

halamix2 · halamix2 · commit 15e12c0f8945 · 2026-06-26T14:49:35.000+02:00
Split out from #2594 to keep the docs review separate from the runtime/controller code changes. - docs/user/00-80-migrate-to-new-runtime-api.md: new migration guide - docs/user/00-90-runtime-deprecation-schedule.md: schedule for legacy runtimes - docs/user/technical-reference/05-20-env-variables.md: env var renames - docs/user/technical-reference/07-70-function-specification.md: SDK reference - components/runtimes/{nodejs26,python314}/README_template.md: ejected workspace README (shipped via kyma function eject)
diff --git a/components/runtimes/nodejs26/README_template.md b/components/runtimes/nodejs26/README_template.md
@@ -1,45 +1,48 @@
 # Ejected Functions Workspace
 
-This folder contains the most important block to test, run, deploy, and productize your business application and consists of the following elements:
+This folder contains the files you need to test, run, deploy, and productize your business application:
 
-* `handler.js` - source code of the buisness application
-* `server.mjs` - server source code required to run `handler.js`
-* `package.json` - dependencies file required for the `handler.js` and the `server.mjs` files to run
-* `lib/` - directory containing server SDK (like cloudevents or tracing functionality)
-* `resources/` - directory with basic Kubernetes resources required to deploy the application on a cluster
-* `Dockerfile` - application image definition
-* `Makefile` - basic portion of automations and scripts
+* `handler.js` — source code of your business application
+* `server.mjs` — server that loads and runs `handler.js`
+* `package.json` — dependencies for `handler.js` and `server.mjs`
+* `lib/` — internal server modules (tracing, metrics, request timeout, and graceful shutdown)
+* `sdk/` — user-facing SDK module (`require('sdk')`) exposing CloudEvent helpers, tracer, and function metadata getters
+* `resources/` — basic Kubernetes resources for deploying the application on a cluster
+* `Dockerfile` — application image definition
+* `Makefile` — automation scripts
 
 ## Scripts and Automations
 
-The `Makefile` file is designed to speed up processes such as running an application locally or building or deploying it on a k3d cluster.
+Use the `Makefile` targets to run the application locally or build and deploy it on a k3d cluster. To see all available targets, run:
 
-Read more about possibilities and functionalites by running the `make help` target.
+```bash
+make help
+```
 
 ### Run Application Locally
 
-> [!NOTE] 
-> Because the application is run outside the cluster, it cannot simply reach in-cluster services and use container envs. It is strongly recommended to use the following target to test the application without such dependencies or mock them and export container envs manually.
+> [!NOTE]
+> When you run the application outside the cluster, it cannot reach in-cluster services or read container environment variables. Use this target to test without such dependencies, or mock them and export the environment variables manually.
 
 ```bash
 export FUNC_NAME=<name>
 export FUNC_RUNTIME=<runtime>
-export SERVICE_NAMESPACE=<SERVICE_NAMESPACE>
+export SERVICE_NAMESPACE=<namespace>
 
 make run
 ```
 
 ### Deploy Application on k3d
 
-The workspace is designed to easily start working on the productization of a business application extracted from Function. It allows testing it on a k3d cluster by building, importing, and deploying it:
+To build, import, and deploy the application on a k3d cluster:
 
 ```bash
 make k3d-deploy
 ```
 
 ### Build and Push Application
 
-Build and push your image to the location specified by `IMG`:
+To build and push your image to the location specified by `IMG`:
 
 ```bash
 make docker-build docker-push IMG=<image>
diff --git a/components/runtimes/python314/README_template.md b/components/runtimes/python314/README_template.md
@@ -1,45 +1,47 @@
 # Ejected Functions Workspace
 
-This folder contains the most important block to test, run, deploy, and productize your business application and consists of the following elements:
-
-* `handler.py` - source code of the buisness application
-* `server.py` - server source code required to run `handler.py`
-* `requirements.txt` - dependencies file required for the `handler.py` and the `server.py` files to run
-* `lib/` - directory containing server SDK (like cloudevents or tracing functionality)
-* `resources/` - directory with basic Kubernetes resources required to deploy the application on a cluster
-* `Dockerfile` - application image definition
-* `Makefile` - basic portion of automations and scripts
-   
+This folder contains the files you need to test, run, deploy, and productize your business application:
+
+* `handler.py` — source code of your business application
+* `server.py` — server that loads and runs `handler.py`
+* `requirements.txt` — dependencies for `handler.py` and `server.py`
+* `lib/` — server SDK modules (CloudEvents, tracing, and similar)
+* `resources/` — basic Kubernetes resources for deploying the application on a cluster
+* `Dockerfile` — application image definition
+* `Makefile` — automation scripts
+
 ## Scripts and Automations
 
-The `Makefile` file is designed to speed up processes such as running an application locally or building or deploying it on a k3d cluster.
+Use the `Makefile` targets to run the application locally or build and deploy it on a k3d cluster. To see all available targets, run:
 
-Read more about possibilities and functionalites by running the `make help` target.
+```bash
+make help
+```
 
 ### Run Application Locally
 
-> [!NOTE] 
-> Because the application is run outside the cluster, it cannot simply reach in-cluster services and use container envs. It is strongly recommended to use the following target to test the application without such dependencies or mock them and export container envs manually.
+> [!NOTE]
+> When you run the application outside the cluster, it cannot reach in-cluster services or read container environment variables. Use this target to test without such dependencies, or mock them and export the environment variables manually.
 
 ```bash
 export FUNC_NAME=<name>
 export FUNC_RUNTIME=<runtime>
-export SERVICE_NAMESPACE=<SERVICE_NAMESPACE>
+export SERVICE_NAMESPACE=<namespace>
 
 make run
 ```
 
 ### Deploy Application on k3d
 
-The workspace is designed to easily start working on the productization of a business application extracted from Function. It allows testing it on a k3d cluster by building, importing, and deploying it:
+To build, import, and deploy the application on a k3d cluster:
 
 ```bash
 make k3d-deploy
 ```
 
 ### Build and Push Application
 
-Build and push your image to the location specified by `IMG`:
+To build and push your image to the location specified by `IMG`:
 
 ```bash
 make docker-build docker-push IMG=<image>
diff --git a/docs/user/00-80-migrate-to-new-runtime-api.md b/docs/user/00-80-migrate-to-new-runtime-api.md
@@ -83,16 +83,18 @@ module.exports = {
 
 ```javascript
 // After — sdk functions
-import { getTracer, getFunctionName, getNamespace, getRuntime, getTimeout, getBodySizeLimit } from 'sdk';
-
-export function main(req, res) {
-    const tracer = getTracer();
-    console.log(getFunctionName());
-    console.log(getNamespace());
-    console.log(getRuntime());
-    console.log(getTimeout());
-    console.log(getBodySizeLimit());
-    res.send('ok');
+const { getTracer, getFunctionName, getNamespace, getRuntime, getTimeout, getBodySizeLimit } = require('sdk');
+
+module.exports = {
+    main: async function (req, res) {
+        const tracer = getTracer();
+        console.log(getFunctionName());
+        console.log(getNamespace());
+        console.log(getRuntime());
+        console.log(getTimeout());
+        console.log(getBodySizeLimit());
+        res.send('ok');
+    }
 }
 ```
 
@@ -157,22 +159,24 @@ module.exports = {
 
 ```javascript
 // After — getCloudEvent() returns a standard CloudEvent object
-import { getCloudEvent } from 'sdk';
-
-export function main(req, res) {
-    const ce = getCloudEvent(req);
-    if (ce) {
-        console.log(ce.type);
-        console.log(ce.source);
-        console.log(ce.specversion);
-        console.log(ce.id);
-        console.log(ce.time);
-        console.log(ce.datacontenttype);
-        console.log(ce.data);
-        res.send(ce.type);
-        return;
+const { getCloudEvent } = require('sdk');
+
+module.exports = {
+    main: function (req, res) {
+        const ce = getCloudEvent(req);
+        if (ce) {
+            console.log(ce.type);
+            console.log(ce.source);
+            console.log(ce.specversion);
+            console.log(ce.id);
+            console.log(ce.time);
+            console.log(ce.datacontenttype);
+            console.log(ce.data);
+            res.send(ce.type);
+            return;
+        }
+        res.send("not a cloud event");
     }
-    res.send("not a cloud event");
 }
 ```
 
@@ -239,15 +243,17 @@ module.exports = {
 
 ```javascript
 // After
-import { emitCloudEvent } from 'sdk';
+const { emitCloudEvent } = require('sdk');
 
-export async function main(req, res) {
-    await emitCloudEvent(
-        'com.example.order.created',
-        '/orders',
-        { orderId: '123' }
-    );
-    res.send("event emitted");
+module.exports = {
+    main: async function (req, res) {
+        await emitCloudEvent(
+            'com.example.order.created',
+            '/orders',
+            { orderId: '123' }
+        );
+        res.send("event emitted");
+    }
 }
 ```
 
diff --git a/docs/user/00-90-runtime-deprecation-schedule.md b/docs/user/00-90-runtime-deprecation-schedule.md
@@ -9,6 +9,7 @@ This document outlines the planned deprecation and end-of-life (EOL) dates for s
 | Node.js 20 | February 2026 | April 2026 |
 | Node.js 22 | July 2026 | November 2026 |
 | Node.js 24 | TBD | TBD |
+| Node.js 26 | TBD | TBD |
 | Python 3.12 | September 2026 | March 2027 |
 | Python 3.14 | TBD | TBD |
 
diff --git a/docs/user/technical-reference/07-70-function-specification.md b/docs/user/technical-reference/07-70-function-specification.md
@@ -371,7 +371,7 @@ You can use a custom runtime image to override the existing one. Your image must
 
 - Expose the workload endpoint on the right port
 - Provide liveness and readiness check endpoints at `/healthz`
-- Fetch sources from the path under the `KUBELESS_INSTALL_VOLUME` environment
+- Fetch sources from the path under the `HANDLER_PATH` environment
 - Security support. Kyma runtimes are secure by default. You only need to protect your images.
 
 Every Function's Pods container has the same system environments, which helps you configure the Functions server. For more information, read the [Environment variables](05-20-env-variables.md) page.
