Alibaba Cloud SDK for PHP V1.0: still shipping, officially on the way out

The package that documents its own replacement

The first thing to know about aliyun/openapi-sdk-php is that its documentation opens with a deprecation notice rather than a feature list. The Alibaba Cloud V1.0 PHP SDK has entered the basic security maintenance phase and is no longer recommended for use, and both new users and users who have already integrated it are advised to migrate to the V2.0 PHP SDK, which lives in a different repository at aliyun/alibabacloud-php-sdk. The wording is unusually direct for a vendor SDK. This is not an abandoned archive, though: the repository is not archived, the last push was on 2026-10-20, and version 1.8.2348 shipped on the same day, following 1.8.2347 and 1.8.2346 earlier in October. So you are looking at a project that is still being built and released while its maintainers tell you to move. The release numbers, now past 1.8.2348, show how much surface the generator covers.

One Composer package covers many products through a fluent client

The package is installed as a single Composer dependency named alibabacloud/sdk, and it exposes generated clients for individual Alibaba Cloud products. The documented example imports four namespaces: the top level AlibabaCloud class, the ClientException and ServerException error types, and the Ecs class for the Elastic Compute Service. A global client is created from an access key pair, given a region, and registered as the default client, after which product API calls are made through a static entry point such as Ecs::v20140526(). The date suffix is the API version. Everything else follows from the builder pattern: request parameters are attached with with-prefixed methods, client and debug behaviour are switched on the same chain, and the request is finally executed. This is a generated surface, which means the ergonomics are uniform across products rather than hand-tuned per service.

Installing the package and configuring a default client

Installation is a single Composer command run in the base directory of your project, and the prerequisites call for PHP 5.5 or newer compiled with the cURL extension, with cURL 7.16.2 or newer strongly recommended. A separate installation document in the repository covers Composer and other methods. Once the package is present, the first thing you do is build a client. The snippet below creates a global client from an access key and region and marks it as the default, which is the point after which product calls can be made without passing credentials around.

composer require alibabacloud/sdk

The client setup that follows runs in PHP:

<?php

use AlibabaCloud\Client\AlibabaCloud;
use AlibabaCloud\Client\Exception\ClientException;
use AlibabaCloud\Client\Exception\ServerException;
use AlibabaCloud\Ecs\Ecs;

// Set up a global client
AlibabaCloud::accessKeyClient('foo', 'bar')
            ->regionId('cn-hangzhou')
            ->asDefaultClient();

Request options can be set inline or through an array

Every call accepts the same option surface, whether you attach it method by method or pass an array. The inline form is the readable one: API parameters such as ResourceType and InstanceChargeType are set with their with-methods, then client selection, debug output, connect timeout and overall timeout follow. Both timeouts are expressed in the same style, and the inline comments in the README note that the debug flag prints detailed information about the call. The array form exists for cases where you want to hold configuration in one place, with debug, connect_timeout, timeout and a query map. The documented precedence rule is that later calls overwrite earlier ones, and the example shows a value in a constructor being replaced by a later options call, then replaced again.

    // Set options/parameters and execute request
    $result = $request->withResourceType('type') // API parameter
                      ->withInstanceChargeType('type') // API parameter
                      ->client('client1') // Specify the client for send
                      ->debug(true) // Enable the debug will output detailed information
                      ->connectTimeout(0.01) // Throw an exception when Connection timeout 
                      ->timeout(0.01) // Throw an exception when timeout 
                      ->request(); // Execution request

ClientException and ServerException split the two failure kinds

Error handling is where a generated SDK either earns trust or loses it, and the shape here is simple and explicit. ClientException covers failures on the caller's side and ServerException covers errors returned by the service, and each is caught separately. The server branch is the more informative one: it prints the message, the error code, the request id and the error message as four separate pieces of information. The request id matters more than it looks, because the project points to an OpenAPI diagnosis service that helps developers locate problems through a RequestID or an error message. That is the practical loop when a call fails in production: read the request id out of the exception and hand it to the diagnostic service. Client errors, by contrast, carry only a message.

Only some products are covered by generated classes

Coverage is the constraint that decides whether this package is useful to you. The documentation states that currently only some Alibaba Cloud products are supported, and points to a supported products list for the detail. For a product that is not on that list, you fall back to a generic Alibaba Cloud client for PHP to initiate custom requests, and the OpenAPI Developer Portal can generate that client code for you online. So the SDK has two layers: generated product classes for the services that are covered, and a generic client for everything else. The same portal is also described as a place to call cloud product OpenAPI online and to generate SDK example code, which makes it a useful companion when you are learning the request format for a service the SDK does not model.

Where the V1.0 package is the wrong choice

There are two separate reasons, and they apply to different readers. For someone starting an integration, the vendor has already answered the question: V1.0 is in basic security maintenance and the V2.0 SDK is the recommended path, so picking V1.0 means picking up a security-only maintenance commitment and a future migration. For someone who already runs V1.0 in production, the more practical problem is the other one, which is that the request grammar is generated per product. A migration to V2.0 is not a package swap if your code depends on with-methods, on the options precedence rules, or on the specific exception classes, because the V2.0 package is a separate repository with its own integration documentation and its own API surface. The version numbers here also warn against expecting a stable 1.0.0, since 1.8.2348 is what ships.

Licensing, repository layout and what an upgrade touches

The project points to an Apache-2.0 licence file and the copyright notice credits Alibaba Cloud with rights reserved from 2009 onward, while the repository is filed with a custom licence classification that GitHub cannot categorise, so anyone building a compliance process should read LICENSE.md and NOTICE.md directly rather than rely on a badge. The layout tells you where the effort of an upgrade sits: src for the library, demo for per-product sample scripts such as the alimt, dysmsapi, green, nlp, ocr and file transfer examples, docs for the English and Chinese documentation set, tests with a PHPUnit configuration, plus composer.json and composer.php at the root and an UPGRADING.md file and a detailed CHANGELOG.md. The release notes are per version, which is what you want when you are deciding whether a specific release contains a fix for a bug you hit. The default branch is master, and the package is published on Packagist as alibabacloud/sdk.

Editorial conclusion

Adopt the V1.0 alibabacloud/sdk package only if you are maintaining an existing integration that has not yet moved, since it still ships releases and the API surface is stable. Do not start new work on it: the project states that V1.0 has entered basic security maintenance and directs both new and existing users to the V2.0 SDK at aliyun/alibabacloud-php-sdk. Before you do anything else, check whether the services you call appear in the SUPPORTED-EN list, because products outside it require hand-written requests, and confirm your PHP version meets the stated requirement of 5.5 or newer with cURL 7.16.2.

Frequently asked questions

Official sources

1. aliyun/openapi-sdk-php on GitHub
2. Issues
3. Project website
4. README
5. Releases