- How do I install graham-campbell/digitalocean in a Laravel app?
- Install it with Composer using composer require graham-campbell/digitalocean. On modern Laravel the service provider and DigitalOcean facade alias are auto-discovered, so no manual registration is needed. Then publish the config file with php artisan vendor:publish and add your API token to .env. A smoke test against a sandbox DigitalOcean account takes an afternoon.
- Which Laravel and PHP versions does this DigitalOcean package support?
- The package tracks Laravel with an eleven-major-version release history, and each release pins its own Laravel and PHP constraints in composer.json. Always check the require block of the specific version you install rather than assuming compatibility with your target framework. Single-maintainer bridges typically lag new Laravel majors by weeks to months, so verify the support matrix before a framework upgrade. Run composer why-not to see what is blocking a version bump.
- How do I set my DigitalOcean API token and publish the config?
- Publish the config with php artisan vendor:publish, then set your token in the .env file under the key the config file references. The config also defines named connections, so you can keep separate tokens per environment or account. Never commit the token; use scoped DigitalOcean tokens with documented rotation. The package provides no credential guardrails, so isolation and rotation are your responsibility.
- What DigitalOcean resources can I manage with this package?
- Anything the upstream DigitalOcean PHP SDK exposes, reached through Laravel's container and facade. In practice that means listing and creating Droplets, sizes, regions, and images, managing volumes, DNS records, snapshots, and triggering actions. There is no repository layer or domain model, so pagination loops, droplet-ID bookkeeping, and ownership tag conventions are hand-written. The package removes framework boilerplate and nothing else.
- Can I configure multiple DigitalOcean connections or accounts?
- Yes, the manager resolves named connections defined in the published config file, so you can register several accounts or per-environment credentials. What it does not support is dynamic per-tenant credentials loaded at runtime from a database. If customers bring their own tokens, this package is the wrong shape and you should resolve the SDK client yourself. For a fixed set of internal accounts, the named-connection approach works fine.
- Does the package handle rate limits, retries, or waiting for droplet actions?
- No. There is no retry or backoff policy, no rate-limit governor, and no wait-for-action polling helper. Those behaviors live in your application code or in a job layer you build on top of the facade. The upstream SDK's HTTP client settings, including proxy, CA bundle, and timeout configuration, govern transport behavior. Treat idempotency, tagging, and action-status polling as your work, not the package's.
- How do I test Laravel code that calls the DigitalOcean API through this package?
- Swap the container binding or mock the DigitalOcean facade in your test suite so calls never hit the real API. The package ships no dedicated fake or testing helpers, so most teams bind a stub of the underlying SDK client in the test container. For integration tests, point at a sandbox DigitalOcean account with a scoped, disposable token. Keep destructive operations out of test paths entirely.
- Is it safe to use this package for droplet create and destroy operations in production?
- The token you inject is a live credential with create and destroy authority over billable infrastructure, and the package adds no guardrails around it. Start with internal-only endpoints or Artisan commands for destructive operations rather than exposing them to web requests. Use scoped DigitalOcean tokens with per-environment isolation and documented rotation. Audit logging and confirmation steps are yours to add.
- Is graham-campbell/digitalocean still maintained, and what happens if it is abandoned?
- It has a long eleven-major-version release history under a single maintainer, so the realistic risk is Laravel major-version lag rather than sudden disappearance. Because the codebase is only a few hundred lines of glue around the upstream SDK, abandonment costs an afternoon of vendoring or inlining the service provider, not a replatforming project. Check release recency, open-issue triage, and CI status on the live repository before committing. Ignore stale metric zeros and verify adoption signals directly.
- How does this compare to using the official digitalocean/digitalocean PHP SDK directly?
- This package is a thin Laravel wrapper around that SDK: a service provider, publishable config, container bindings, a named-connection manager, and a facade. Every capability still comes from the upstream client, so the only thing you save is framework boilerplate. If you are not Laravel-first, or you need per-tenant credentials resolved dynamically, use the SDK directly. If you are Laravel-first and standardized on DigitalOcean, the wrapper is a low-stakes convenience.