This topic describes the background information, basic principles, environments, configuration requirements, common request headers, and log specifications of a custom runtime.

Background information

A custom runtime is a custom runtime environment. In the custom runtime, you can

  • Customize execution environments for personalized languages (such as Go, Lua, and Ruby) and minor versions of languages (such as Python 3.7 and Node.js 12) to create your own runtime.
  • Migrate existing web applications or traditional web projects to Function Compute with a single click.

How it works

A custom runtime is essentially an HTTP server. To create a custom runtime, you only need to perform the following operations: build an HTTP server that listens on a fixed port, store the command used to start this server in a file named bootstrap, compress the bootstrap file and your code file into a ZIP package, and create a custom runtime function by using the ZIP package as the code package.

To cold start the custom runtime, Function Compute calls the bootstrap file by default to start your custom HTTP server. Then, the HTTP server takes over all requests from Function Compute, including event invocations and HTTP function invocations.principle


A custom runtime supports the following languages. You can create a custom runtime in the following languages without installing a third-party interpreter:

  • Python 3.7.4 or later
  • Node.js 10.16.2 or later
  • Open JDK 1.8.0 (Open JDK 1.8.0_232)

HTTP server configuration requirements

To create an HTTP server, you must ensure that the following requirements are met:

  • The services started in a custom runtime must listen on the or *:9000 port. If you select the port, the request times out and the following error occurs:
     {"ErrorCode":"FunctionNotStarted","ErrorMessage":"The CA's http server cannot be started:ContainerStartDuration:25000000000. Ping CA failed due to: dial tcp getsockopt: connection refused Logs : 2019-11-29T09:53:30.859837462Z Listening on port 9000\r\n"}                   
  • The bootstrap file of the custom runtime must contain with#! /bin/bash. Otherwise, the following error occurs:
     {"ErrorCode":"CAExited","ErrorMessage":"The CA process either cannot be started or exited:ContainerStartDuration:25037266905. CA process cannot be started or exited already: rpc error: code = 106 desc = ContainerStartDuration:25000000000. Ping CA failed due to: dial tcp i/o timeout Logs : 2019-11-29T07:27:50.759658265Z panic: standard_init_linux.go:178: exec user process caused \"exec format error\"                     
  • Keep-Alive must be set in the Connection header and the timeout value must be 15 minutes or more. Example:
    // When Node.js uses express.  
    app.timeout = 0; // The quest never times out. 
    app.keepAliveTimeout = 0; 
  • The HTTP server must start up within 30 seconds.

Common request headers in Function Compute

The following table lists the request headers that a custom runtime may receive from Function Compute. If you access other Alibaba Cloud services, you may use request headers of temporary AccessKey pairs. If you migrate existing applications, the following headers are not involved.

Header Description
x-fc-request-id The ID of the request.
x-fc-access-key-id The temporary AccessKey ID.
x-fc-access-key-secret The temporary AccessKey secret.
x-fc-security-token The temporary security token.
x-fc-function-handler The handler of the function. This value is useless if the Runtime is a function.
x-fc-function-memory The maximum memory that a function can use.
x-fc-function-initializer The handler of the initializer function. This value is not required if the Runtime is a function.
x-fc-initialization-timeout The timeout period of the initializer function.
x-fc-region The region of the function.
x-fc-account-id The UID of the function owner.
x-fc-qualifier The service version or alias that is specified when the function is called. For more information, see View the version of a function.
x-fc-version-id The version of the function.
x-fc-service-name The name of the service to which the function belongs.
x-fc-service-logproject The log project configured for the service to which the function belongs.
x-fc-service-logstore The logstore configured for the service to which the function belongs.
x-fc-control-path The type of the request.

Function log formats

We recommend that you select Log Service when you create a service. Then, all log records in the custom runtime that are sent to the terminal are saved in the specified Log Service project. For more information, see Configure and view function logs.

If Function Compute calls the function in other runtimes (except the custom runtime), and the request header contains x-fc-log-type" = "Tail", the x-fc-log-result contained in the response header is the log record generated when the function is executed. The maximum size of this log record is 4 KB. You can view the log record in the function execution results in the Function Compute console. If you want to view the operational logs of the custom runtime in the execution results of the console, you must record the start and end logs of the request in the code.

Content Required Code
Start runtime No
Note The flag for cold start of the function.
FunctionCompute ${runtime} runtime inited.
Note If you use the Go language, ${runtime} is custom. We recommend that you do not use an official language name, such as Node.js, Python, or PHP.
Invoke start log Yes FC Invoke Start RequestId: ${RequestId}
Invoke end log Yes FC Invoke End RequestId: ${RequestId}
Initialize start log No
Note For the initializer function, this log must be recorded.
FC Initialize Start RequestId: ${RequestId}
Initialize end log No
Note For the initializer function, this log must be recorded.
FC Initialize End RequestId: ${RequestId}
In addition to the preceding fields, the request ID is also recommended to facilitate future troubleshooting. We recommend that use the $utcdatetime(yyyy-mm-ddthh:mm:ss.fff)$requestid[$level]$message format.
Note The API operation to specify the log level varies with languages. For more information, see Log records.


You can refer to the following documents when you create a custom runtime:


For more information about the limits of custom runtimes, see Limits on resource usage.