tencent cloud


WebServer Image Function

Last updated: 2023-07-10 10:28:48

    SCF allows you to deploy container images as functions. This document describes the background, principles, development, log printing, cold start optimization, billing, and use limits of image deployment functions.


    SCF is a FaaS service based on the cloud native architecture from the very beginning of design. After adding support for deploying container images as functions at the runtime layer, its entire service form has evolved towards a containerized ecosystem. On the one hand, it solves the environment dependency problem in function runtime and gives you more freedom to customize. On the other hand, this service form enables you to cross the technical thresholds, such as Kubernetes cluster management, security maintenance, and troubleshooting, and sinks auto scaling, availability, and other needs to the computing platform, further unleashing the capabilities of cloud computing.

    How It Works

    Before developing specific function logic, you need to determine the function type. SCF provides event-triggered functions and HTTP-triggered functions.

    During the initialization of the function instance, SCF will obtain the temporary user name and password of the image repository as the access credential to pull the image. After the image is pulled successfully, start the HTTP Server you defined according to the specified startup command Command, the parameter Args and the port (fixed to 9000). Finally, HTTP Server will receive all entry requests of SCF, including the event-triggered function invocations and HTTP-triggered function invocations.

    How a function works is as shown below:

    Developing Function Deployed Based on Image

    Building HTTP server

    For a function deployed based on an image, you need to build an HTTP server and configure it as follows:

    • It should listen on or *:9000.
    • It should be started within 30 seconds.

    If the above step is not completed, health check may time out, and the following error may be reported:

    The request timed out in 30000ms.Please confirm your http server have enabled listening on port 9000.

    Function input parameters

    • event: POST request body (HTTP body)
      The request body contains the event data. For its structure, see Trigger Event Message Structure Summary.

    • context: Request header (HTTP header)

      • Common parameters: Parameters used to identify the user and API signature, which must be carried in each request.
      • Use X-Scf-Request-Id to get the current request ID.
      • Both event-triggered and HTTP-triggered functions contain common headers.
      • The common request headers are generated by SCF, which mainly contain permissions and basic function information.
      • The input parameters are as detailed below:
        Header Field Description
        X-Scf-Request-Id Current request ID
        X-Scf-Memory Maximum memory that can be used during function instance execution
        X-Scf-Timeout Timeout period for function execution
        X-Scf-Version Function version
        X-Scf-Name Function name
        X-Scf-Namespace Function namespace
        X-Scf-Region Function region
        X-Scf-Appid `Appid` of function owner
        X-Scf-Uin `Uin` of function owner
        X-Scf-Session-Token Temporary `SESSION TOKEN`
        X-Scf-Secret-Id Temporary `SECRET ID`
        X-Scf-Secret-Key Temporary `SECRET KEY`
        X-Scf-Trigger-Src Timer (if a scheduled trigger is used)

    Built-in environment variables

    Environment variables built in the container in custom image-based deployment are different from those in code package-based deployment. You can import them as needed.

    Environment Variable Key Specific Value or Value Source
    USER_CODE_ROOT /var/user/
    USER qcloud
    SCF_FUNCTIONNAME Function name
    SCF_FUNCTIONVERSION Function version

    Function invocation

    • For event-triggered functions, you need to listen on the fixed path /event-invoke to receive function invocation requests.
    • For HTTP-triggered functions, you don't need to listen on a specified path; instead, API Gateway uses layer-7 reverse proxy to pass through the request path.

    Function log printing

    SCF collects standard output logs such as stdout and stderr generated in the container in a non-intrusive manner and reports them to the log module. After invoking a function, you can view the aggregated logs in the console.

    Cold Start Optimization

    As file layers such as basic environment and system dependency are added to the image, compared with code package-based function deployment where files are completely built-in, image-based function deployment requires extra file download and image decompression time. To further reduce the cold start time, we recommend you use the following practices:

    Downsizing image

    • Create an image repository and a function in the same region, so that the image can be pulled over VPC when the function triggers image pull, which makes the pull faster and more stable.
    • The image should be as small as possible, that is, it should contain only the necessary basic environment and execution dependencies without any unnecessary files.

    Enabling image acceleration

    After image acceleration is enabled, the function platform will prefetch the image nearby through the internal acceleration mechanism. When calling a function instance, it will directly load and decompress the image from the cache, eliminating the time for downloading the image file. This expedites the launch by five times on average.


    1. Log in to the SCF console and select Functions on the left sidebar.
    2. On the Functions list page, select the name of the target image function.
    3. Select Function codes on the Function management page.
    4. On the Function codes page, click Edit.
    5. Select *Enable in Image acceleration.
    6. Click Save.


    This feature is currently in beta test free of charge. Acceleration can be enabled for up to five functions in one region under each account.

    Using provisioned concurrency

    Use provisioned concurrency when deploying an image to start a function instance in advance and thus reduce the cold start time and optimize the user experience. For more information, see Provisioned Concurrency.


    The billable items of image-based functions are the same as those of code package-based functions. For more information on billing, see Pay-As-You-Go (Postpaid).

    Use Limits

    Image size

    Currently, only images below 1 GiB in size are supported. We recommend you select an appropriate function instance execution memory based on the image size. To increase the limit, submit a ticket for application.

    Image Size (X) Execution Memory (Y)
    X < 256 MB 256 MB < Y < 512 MB
    256 MB < X < 512 MB 512 MB < Y < 1 GiB
    512 MB < X < 1 GiB Y > 1 GiB

    Image repository access

    Permission to read/write file in container

    • /tmp is readable and writable by default. We recommend you select /tmp when outputting a file.
    • Avoid using other users' files with restricted access or execution.
    • The storage space of the writable layer in the container is 512 MB.

    CPU architecture limits for image build client

    Currently, SCF functions run on the x86 architecture, so images built on the ARM platform (such as Apple Mac with M1 chip) are not supported.

    Image build client limits

    The client should meet one of the following requirements:

    • Docker Image Manifest v2, Schema 2 (Docker should be on v1.10 or later)
    • Open Container Initiative (OCI) Specifications (v1.0.0 or later)
    Contact Us

    Contact our sales team or business advisors to help your business.

    Technical Support

    Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

    7x24 Phone Support