Alibaba Function Compute Legacy Runtime Migration — when and how should I migrate?

Decide whether to upgrade off aging managed runtimes or move to custom runtimes and containers as Alibaba Function Compute deprecates language versions after upstream EOL.

Upgrade to the newest supported built-in runtime if your code fits Alibaba's managed matrix; move to a custom container only when you need strict OS or native dependency control.

Blockers

Who this is for

Candidates

Upgrade to the newest supported built-in runtime

This keeps you on Alibaba Function Compute managed runtimes and minimizes operational overhead. As of 2026-04-02, the runtime overview lists current built-in options including Node.js 20.x and 18.x, Python 3.12 in public preview, Python 3.10, Java 11 and 8, .NET Core 3.1, Go 1.x, and PHP 7.2. Function Compute deprecation follows a two-phase policy tied to upstream language end of life, but the published deprecation table is the practical decision point: for example, Node.js 10 and 8 reached Phase 2 on 2024-12-15, while Python 2.7, .NET Core 2.1, Node.js 6, and Node.js 4.4 reached Phase 2 on 2024-09-25.

When to choose

Use this when you can stay within the managed runtime matrix and want the lowest migration complexity plus ongoing Alibaba maintenance. It is the default choice if your code can move to Node.js 20, Node.js 18, Python 3.10, or another currently listed built-in runtime without needing OS or interpreter control.

Tradeoffs

Least operational burden and simplest deployment model, but you are limited to Alibaba's published runtime and OS combinations. You may also be forced onto older OS bases for some managed runtimes, such as Debian 9 or Debian 10, until Alibaba refreshes them.

Cautions

Do not assume upstream EOL automatically means an immediate Alibaba hard block on the same date. As of 2026-04-02, Node.js 12 is still listed as supported and its published deprecation table entry shows no Phase 1 or Phase 2 date, so you must check Alibaba's runtime table rather than infer dates from upstream alone.

Sources

Move to a custom runtime on newer Debian bases

This keeps you on Function Compute while taking control of the language executable and startup command. As of 2026-04-02, the custom runtime docs list Debian 12 in public preview, plus Debian 11, Debian 10, and Debian 9; Debian 12 preview is limited to selected China regions. The newer custom runtime images also include built-in interpreters such as Python 3.11.2 on Debian 12, Python 3.12.4 on Debian 11, and Node.js 20 v20.10.0 plus Node.js 18 v18.19.0 on Debian 10. As of 2026-04-02, Function Compute billing is still described in the billing overview as CU-based, so this is mainly a compatibility and lifecycle-control choice rather than a different base compute pricing model.

When to choose

Use this when managed runtimes lag the language or OS combination you need, but you still want Function Compute's ZIP-style workflow instead of full container operations. It is also the documented recommendation for web scenarios in the function creation flow.

Tradeoffs

You gain control over interpreter versioning and startup behavior without taking on a full container image pipeline. In exchange, you must manage bootstrap commands, environment variables, and packaged runtimes or layers yourself.

Cautions

Custom runtime Debian 12 is public preview and region-limited, so do not standardize on it unless those regions match your deployment footprint. If you use a non-built-in language or version, you must package the interpreter or runtime with your code and maintain that artifact yourself.

Sources

Move to a custom container function

This gives you the most control because you deploy a container image instead of depending on Alibaba's managed language packages. Alibaba positions this path for cases where Function Compute environments do not meet business requirements, and the create flow supports start command overrides, a default HTTP listening port of 9000, and CPU or GPU selection. As of 2026-04-02, custom container functions must use an image from Alibaba Cloud Container Registry in the same region and same account, and if you build on an ARM-based computer such as an Apple silicon Mac, you must specify the image build platform as linux/amd64. For Enterprise Edition ACR images, Alibaba recommends immutable tags; for ACR Personal Edition or Enterprise Basic, reusing a tag requires an explicit function update before new instances use the updated image.

When to choose

Use this when you need full OS dependency control, native libraries, or an image-based supply chain that matches the rest of your platform. It is the decisive option when runtime portability and exact reproducibility matter more than the lower-ops experience of managed or custom runtimes.

Tradeoffs

Maximum control and consistency with container-based delivery, but more moving parts than built-in or custom runtime functions. You add registry, image build, and image lifecycle concerns to the migration.

Cautions

This path adds an ACR dependency and same-account same-region constraint, which can complicate multi-account or centralized registry setups. For web workloads, Alibaba's console guidance still recommends custom runtime rather than container image as the default path, so choose container only when the extra control is actually needed.

Sources

Facts updated: 2026-04-02
Published: 2026-04-03

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Alibaba Function Compute Legacy Runtime Migration — when and how should I migrate?"
Missing something? Request coverage