skydiablo/aws-bundle
skydiablo/aws-bundle is a Symfony bundle for integrating the AWS SDK into PHP applications, providing container configuration and service wiring to simplify access to AWS services such as S3, SES, and SQS.
First, a caveat about context. This is a Symfony bundle (skydiablo/aws-bundle), not a Laravel package. In Laravel you would not normally install a Symfony bundle — bundles register services through Symfony's kernel and services.yaml/Extension classes, which Laravel's container does not process. If you are working in a Laravel app, the practical path is the AWS SDK directly (aws/aws-sdk-php) or league/flysystem-aws-s3-v3 for storage; there is no adapter layer here for Laravel's service container or facades.
Second, a caveat about the package itself. 0 stars, 0 forks, 0 dependents, and a one-line description ("AWS Helper") are strong signals of an abandoned or personal-scratch package. Before writing a single line of integration code:
composer.json first. Check the require for symfony/* and aws/aws-sdk-php version constraints. If those pin to Symfony 2/3 or AWS SDK v2, the package is effectively dead and you should stop.README.md for a config example. Bundles typically expose a config/packages/skydiablo_aws.yaml-style tree. If the README has no working config block, treat the bundle as undocumented and read DependencyInjection/Configuration.php directly — that file is the real spec.DependencyInjection/ and Resources/config/. Service IDs, argument wiring, and any %env()% placeholders will tell you what is actually available. This is the "documentation" for an unmaintained bundle.First real use case (if it checks out): registering a shared S3 client as a service so controllers/consumers don't construct new S3Client([...]) by hand. That is the only thing a thin "AWS helper" bundle realistically buys you — centralised credential/region config and a service you can inject. If that is what you want, confirm the bundle actually does that before building on it.
Verdict before you start: for a new project, install aws/aws-sdk-php directly and register the client yourself. It is a handful of lines, you control the version, and you avoid inheriting a 0-dependency package with no maintenance signal.
Assuming you have verified the bundle is compatible and functional, the patterns are the standard Symfony bundle idioms — mirror these against the actual source, since names below are illustrative:
Service injection over construction. Let the bundle own the client and inject it:
// Controller — inject the bundle-registered client service
use Aws\S3\S3Client;
public function __construct(private S3Client $s3) {}
Do not fall back to new S3Client() inside controllers "just in case" — you lose the single place to change credentials/region, which is the only benefit the bundle offers.
Configuration via env vars, not literals. Bundle config should reference %env(AWS_ACCESS_KEY_ID)%, %env(AWS_SECRET_ACCESS_KEY)%, %env(AWS_REGION)%. Keep the YAML in config/packages/ and the secrets in .env.local / the real environment. If the bundle's Configuration tree does not support env placeholders for these, add them in your app's config layer rather than editing bundle code.
Per-service client instances. Real apps usually need different clients: S3 for storage, SES for mail, SQS for queues. If the bundle exposes one generic Aws\Sdk/client, either configure it to allow per-service instantiation (Sdk::createClient('s3', [...])) or bypass the bundle for services it does not cover. Wrapping an SDK you don't fully control is worse than two clean clients.
Testing seam. Whatever service the bundle registers, alias it in your test config so you can substitute a fake:
# config/services_test.yaml
services:
_defaults: { public: true }
Aws\S3\S3Client: '@app.fake_s3_client'
If the bundle final-classes its internals or constructs clients with new, this seam won't exist and your test strategy becomes integration-only — a real reason to skip the package.
Integration tips. Prefer a thin application-level wrapper (e.g. App\Storage\S3Uploader) that depends on the bundle's client and exposes only the 3–5 methods your app uses. That isolates you from swapping the bundle out later, which is likely given its maintenance state.
Laravel-specific note. In Laravel, replicate the pattern without the bundle: bind the SDK client as a singleton in a service provider, resolve config from config/filesystems.php / config/services.php, and inject. That is the equivalent-and-safer implementation of what a Symfony AWS bundle offers.
composer.json (exact X.Y.Z, not ^), and be prepared to vendor/fork it.Symfony\Component\HttpKernel\Bundle\Bundle often also implement ExtensionInterface; the latter changed method signatures over Symfony majors. Check it compiles against your Symfony version — a fatal error at kernel boot is common here.~/.aws/credentials file, then IAM roles. If the bundle hard-codes arguments, environment variables can appear to be ignored. Log the effective region/credentials source when debugging rather than guessing.PermanentRedirect or NoSuchBucket for a bucket that exists. Confirm the configured region matches the bucket.Configuration.php defaults surfaced in docs, a bundle may default to us-east-1 or an empty region. Read the tree and set everything explicitly.aws/aws-sdk-php client outside the bundle (few lines in tinker/a script). If it works there, the bundle's wiring is the problem; bisect by dumping the container's service definition (debug:container <service-id> in Symfony).services.yaml — possible, but fragile across updates. Document the override.aws/aws-sdk-php plus Symfony's aws/aws-bundle (the official one) or plain DI registration for Symfony; aws/aws-sdk-php bound in a service provider for Laravel. Both have far better maintenance signals than this package.How can I help you explore Laravel packages today?