All Products
Search

This Product

    Function Compute:Custom images (Custom Container)

    Document Center

    Function Compute:Custom images (Custom Container)

    Last Updated:Sep 24, 2025

    This topic describes the background, basic principles, limits, and HTTP Server configuration requirements of custom images.

    Background information

    In the cloud-native era, container images have become a standard tool for software deployment and development. To optimize the developer experience and improve development and delivery efficiency, Function Compute provides custom images. This allows developers to use container images as function deliverables. Using custom images provides the following benefits:

    • Low-cost migration without code modification or binary file recompilation. You can share object files (*.so) to keep development and production environments consistent.

    • Simplify distribution and deployment by packaging code and dependencies together.

    • Improve code upload and pull efficiency through layered caching.

    • Leverage the rich continuous integration and continuous delivery (CI/CD) experience from the open-source ecosystem. This provides standard and reusable methods for referencing, sharing, building, uploading, storing, and managing versions of third-party libraries and code.

    • Interact with the Function Compute system through the HTTP protocol.

    • Run non-interactive images.

    How it works

    Before the Function Compute system initializes an execution environment instance, it assumes the service role of the function. It then obtains a temporary username and password to pull the image. After the image is pulled, it is started using the specified startup command (Command) and arguments (Args).

    The container image must include an HTTP server. Function Compute listens to your custom HTTP server on the configured `CAPort`. This server handles all requests to Function Compute, including API calls and HTTP calls. Before you develop the interaction logic for a function, you must determine whether the function will be invoked by an API call or an HTTP request. The principles are as follows:

    • Invoke a function by an API callbuhuo1containercustom1

    • Invoke a function by an HTTP requestnuhuo2customcintainer2

    Limits

    Image size limit

    For ACR Personal Edition or Enterprise Edition (Basic, Standard, or Premium), the maximum uncompressed image size is 10 GB for CPU instances and 15 GB for GPU-accelerated instances.

    Image repository

    Function Compute supports pulling images from Container Registry Enterprise Edition and Personal Edition repositories.

    Note

    ACR Economy Edition instances do not support image acceleration. Therefore, Function Compute does not support image repositories in ACR Economy Edition instances. To create or update a function, you must use an image from an ACR Personal Edition or Enterprise Edition (Basic, Standard, or Premium) instance.

    Image access

    Currently, only public images in ACR Personal Edition can be accessed by other accounts within the same region. Other images can only be accessed from private image repositories within the same account and region.

    File read and write permissions in containers

    By default, a container runs as the root user (UID=0). If you specify a user in the Dockerfile, the container image runs as that user.

    Writable layer storage limit for containers

    The container's writable layer is limited to 512 MB or 10 GB. This limit corresponds to the disk size specified in the advanced configuration of the function. For more information, see Create a function.

    Note

    Data in the writable layer of a container is not persistent. The data is deleted when the container is destroyed. For persistent storage, you can mount a NAS file system or an OSS bucket in Function Compute. For more information, see Configure a NAS file system and Configure Object Storage Service. You can also use other shared storage services, such as Tablestore.

    Image architecture limit

    Currently, Function Compute only supports the AMD64 image architecture. Therefore, if you build an image on a Mac with an Apple chip or another machine with an ARM architecture, you must specify the build platform as `linux/amd64`. An example command is docker build --platform linux/amd64 -t $IMAGE_NAME ..

    Note

    After the build is complete, you can run docker inspect to check the architecture. If the output contains "Architecture" : "amd64", the image is built correctly.

    HTTP Server configuration requirements

    The following requirements apply only to custom image functions that use a web server:

    • The service started by the custom image must listen on 0.0.0.0:CAPort or *:CAPort. If the service listens on 127.0.0.1:CAPort, requests time out and the following error occurs:

      {
    "ErrorCode":"FunctionNotStarted",
    "ErrorMessage":"TheCA'shttpservercannotbestarted:ContainerStartDuration:25000000000.PingCAfaileddueto:dialtcp21.0.XX.XX:9000:getsockopt:connectionrefusedLogs:2019-11-29T09:53:30.859837462ZListeningonport9000"
}

      The listener port for a custom image is defined by the `CAPort` function property, which defaults to 9000. The HTTP server in your custom image must listen on the port specified by `CAPort`. For example, if `CAPort` is set to 8080, your HTTP server must also listen on port 8080.

    • The server must support `Connection: Keep-Alive` and the server-side request timeout period must be set to 15 minutes or longer. The following example shows how to configure the timeout:

      // For example, when using Express in Node.js.  
var server = app.listen(PORT, HOST);
server.timeout = 0; // never timeout
server.keepAliveTimeout = 0; // keepalive, never timeout

    • The HTTP server must start within 120 seconds.

    Common request headers

    The common request headers for custom images are the same as those for custom runtimes. For more information, see Common request headers in Function Compute.

    Log format

    All logs printed to standard output (stdout) in a custom image are automatically collected by the Simple Log Service project that you specify. For more information about how to configure the logging feature, see Configure the logging feature.

    The log format for custom images is the same as that for custom runtimes. For more information, see Function log format.

    Best practices for cold start optimization

    Compared with code packages, container images require extra time to download and decompress the base environment. For a better cold start experience, follow these best practices:

    • Use a VPC image address that is in the same region as Function Compute to reduce image pull latency and improve stability.

    • Minimize the image size. Build your custom image based on a minimal image, such as Alpine or Ubuntu, or a streamlined version of another image. Keep only the necessary dependencies and remove unnecessary documents, data, and other files.

    • Use container images with provisioned instances. For more information, see Configure a minimum instance count elasticity policy.

    • If your resources allow and the function is thread-safe, use the single-instance multiple concurrency feature. This avoids unnecessary cold starts and reduces costs. For more information, see Create a web function.

    Billing

    The billable items for custom images are the same as those for other runtimes. For more information, see Billing overview.

    For image resource usage, the running time is calculated from the start to the end of the image pull from the repository. For example, if it takes 10 seconds for an instance with 1,024 MB of memory to pull an image, the resource usage for this pull is 10 GB-seconds.

    Container images are cached for a period of time. Therefore, image pull fees are not incurred for every cold start.

    References