DigitalOceanPHP Client: a typed PHP wrapper for the DigitalOcean API v2

The client turns REST endpoints into entity and collection calls

DigitalOceanPHP/Client describes itself as a DigitalOcean API v2 client for PHP. The interesting part is not the HTTP call but the shape it gives you. Each API area hangs off the client object, and each of those accessors returns entity objects rather than raw JSON arrays.

// return the account api
$account = $client->account();

// return the Account entity
$userInformation = $account->getUserInformation();

The same pattern applies to actions.

// return the action api
$action  = $client->action();

// return a collection of Action entity
$actions = $action->getAll();

// return the Action entity 123
$action123 = $action->getById(123);

For resources with a lifecycle, the accessor offers the full set of verbs. The app API, for example, exposes create, update and remove alongside getters, plus deployment-level calls such as createAppDeployment, cancelAppDeployment, getAppDeployments, getDeploymentLogs and getAggregateDeploymentLogs, and catalogue calls for regions, tiers and instance sizes.

That object model is the library's whole value. Instead of assembling request paths, query strings and JSON bodies by hand, you work with a documented method surface. The cost is that you inherit the library's interpretation of the API, and its coverage is defined by what the DigitalOcean API exposes, not by anything the client adds.

Composer pulls in the package plus an HTTP client and a factory

Installation is a Composer require, and the README notes that this version supports PHP 8.1 to 8.5. The standard install names the client package and a Guzzle release together.

$ composer require "toin0u/digitalocean-v2:^5.1" "guzzlehttp/guzzle:^7.9.2"

That pairing is not incidental. The library states that it is decoupled from any HTTP messaging client by using PSR-7, PSR-17, PSR-18 and HTTPlug, and it points readers at the HTTPlug documentation for library users. In practice you must install packages that provide psr/http-client-implementation and psr/http-factory-implementation, which is why the Guzzle line appears in the install command.

For frameworks the README lists separate integrations rather than asking you to wire the client yourself. Laravel users are pointed at a package by Graham Campbell.

$ composer require "graham-campbell/digitalocean:^11.1"

The Symfony bundle dunglas/digital-ocean-bundle, by Kévin Dunglas, is named as the other integration, and both are third-party projects rather than part of this repository.

The trade-off is straightforward. Decoupling buys you the freedom to swap the HTTP implementation, and it costs you an extra install step and the need to check that your project already provides those two PSR implementations.

Create the client, authenticate, and the token comes from the API settings page

The first use is short. Since version 3.0 the library discovers an available HTTP client automatically from what you have installed, so there is no factory class to configure by hand. You create the client and authenticate it with an access token.

<?php

require_once 'vendor/autoload.php';

// create a new DigitalOcean client
$client = new DigitalOceanV2\Client();

// authenticate the client with your access token which can be
// generated at https://cloud.digitalocean.com/settings/applications
$client->authenticate('your_access_token');

The token is generated on the applications settings page of the DigitalOcean control panel, as the comment in the README notes. This is the credential that decides what the client can do, so it belongs in your secret storage rather than in source, and the README does not discuss token scoping or rotation.

From there, every accessor on the client is a live API endpoint. The droplet accessor in particular is the one most projects reach for first, and the same accessor supports listing and, as shown in the paginator section, walking collections.

The paginator fetches 100 entries per request and can stream lazily

Collections are the part of the API that punishes naive clients, and version 3.0 added a built-in paginator that can be used on any of the APIs returning collections. By default the pager attempts to fetch 100 entries in each request, and the README says this is configurable by passing a second parameter to the constructor.

// create a new result pager
$pager = new DigitalOceanV2\ResultPager($client);

// get all droplets as an array
$droplets = $pager->fetchAll($client->droplet(), 'getAll');

// get all droplets as a Generator which lazily yields
// new results as they become available
$droplets = $pager->fetchAllLazy($client->droplet(), 'getAll');

The two calls differ in memory behaviour rather than in results. fetchAll materialises everything into an array, which is convenient for small accounts and expensive for large ones. fetchAllLazy returns a Generator that yields results as they arrive, so a script that only needs the first page or wants to stream results does not hold the whole collection in memory.

Note the shape of the call: the pager receives the API accessor and the method name as a string. That keeps the pager independent of any particular endpoint, which is why it works across all collection-returning APIs, and it is also why it is not type-checked at that point.

The repository ships static analysis baselines and Docker-based tooling

Behind the client code the repository is set up like a library that takes its own tooling seriously. The top-level entries include phpstan.neon.dist, a phpstan baseline, psalm.xml with psalm-baseline.xml, phpunit.xml.dist, a Makefile, composer.json, a .stubs directory and vendor-bin/.

The Makefile shows how the maintainer runs things, and every target executes inside a container image rather than on the host.

test: phpunit phpstan-analyze psalm-analyze

Targets exist for phpunit, phpstan-analyze, psalm-analyze and separate baseline generation targets for both analysers, plus an install target that runs Composer inside a container with the project directory mounted. A clean target removes the Composer lock file, the vendor directory and the vendor-bin lock files and vendors.

Two static analysers run side by side on the same codebase, and both carry committed baselines, which is the usual pattern for adopting strict analysis on an existing library without a large cleanup commit. The .stubs directory and vendor-bin/ are the kind of arrangement that keeps analysis-only dependencies out of the production dependency list.

StyleCI is used for formatting checks, and the repository also points to a code of conduct, a contribution guide, a security policy and a changelog.

Major versions move fast and the last push was on 2026-05-06

The versioning history explains a lot. The repository's default branch is named 5.1, and the recent releases include 5.1.0 and 5.1.1, both published on 2026-05-06, and 5.0.5 from 2025-05-03. The README documents an upgrade guide for moving from version 2.3 to 3.0 and from 3.3 to 4.0, and it recommends upgrading as soon as possible.

The license is MIT, with a LICENSE file at the root and a link to the security policy.

Maintenance facts are modest. The repository is not archived, but the last push was on 2026-05-06, so the code has been quiet for a while and the newest tag matches that date. With a library that mirrors a fast-moving provider API, that quiet period is the thing to weigh, because a client that stops moving tends to fall behind the API it wraps.

The version numbering is where the real upgrade cost sits. Two major-version jumps already require reading UPGRADING.md, and the current line is 5.1, so anyone starting on 2.x or 3.x is several breaking changes behind. The client's PHP requirement of 8.1 to 8.5 is a second boundary: it excludes anything still on PHP 8.0 or older, which in practice means the library is only an option for codebases that have already moved.

Editorial conclusion

DigitalOceanPHP/Client fits PHP applications and frameworks that have to create, inspect or tear down DigitalOcean resources, and it fits them best when the team wants typed entities and pagination without hand-rolling HTTP calls. It does not fit a PHP 8.0 or 7.x codebase, since this version supports 8.1 to 8.5, and it does not fit a project that wants a single dependency, because the README requires a package providing psr/http-client-implementation and another providing psr/http-factory-implementation. Before adopting it, check `composer.json` for the exact constraints, confirm the client and factory implementations are already present in your project, and read the upgrade guide if you are moving between major versions such as 2.3 to 3.0 or 3.3 to 4.0.

Frequently asked questions

Official sources

1. DigitalOceanPHP/Client on GitHub
2. Issues
3. License: MIT
4. README
5. Releases