Df Aws Laravel Package

Getting Started

Understand what this actually is first. dreamfactory/df-aws is not a Laravel package you drop into an app — it is a service-type plugin for the DreamFactory platform. DreamFactory itself is a self-hosted API gateway built on Laravel components, and this package registers AWS connectors (aws_s3, aws_sqs, aws_sns, aws_ses, and on newer builds aws_dynamodb, aws_lambda, aws_kinesis) as first-class DreamFactory services. The leverage for a Laravel developer is that DreamFactory auto-generates a governed REST API over those AWS resources, complete with API keys, roles, rate limits, and server-side scripting — so your Laravel app talks HTTP to DreamFactory instead of embedding AWS credentials and SDK calls everywhere.

Prerequisites and install (inside the DreamFactory instance, not your app):

# In the DreamFactory installation root, not your Laravel project
composer require dreamfactory/df-aws
php artisan df:setup        # 4.x; check the docs for the 5.x equivalent
php artisan vendor:publish --provider="DreamFactory\Aws\ServiceProvider"

Then log into the DreamFactory admin UI → Services → Create → AWS S3 (or SQS/SNS/etc.), supply region + credentials (or an instance role), and save. DreamFactory immediately exposes CRUD-style endpoints under /api/v2/{service_name}/....

Where to look first in the repo:

• composer.json — the dreamfactory/core version constraint is the single most important line; it dictates which platform releases you can install into.
• src/ServiceProvider.php and the package registration class — shows the service types being registered and their config schemas.
• src/Services/ — one handler per AWS service; these define the exact endpoint shapes and parameters you'll call.
• README.md / DreamFactory docs for the service's config schema — the admin UI form fields map directly to these.

First use case to prove it out: S3. Configure the aws_s3 service, then hit GET /api/v2/aws_s3/ to list buckets and GET /api/v2/aws_s3/{bucket}/{object} to stream an object. That single round trip validates credentials, region, IAM policy, and your API key — the four things that usually break.

// config/services.php in your Laravel app
'df' => [
    'url' => env('DREAMFACTORY_URL'),
    'key' => env('DREAMFACTORY_API_KEY'),
],

Http::withHeaders(['X-DreamFactory-Api-Key' => config('services.df.key')])
    ->get(config('services.df.url').'/api/v2/aws_s3/')
    ->throw()
    ->json('resource');

Implementation Patterns

1. Credential brokering, not credential sharing. The strongest day-to-day win: Laravel never holds AWS keys. DreamFactory holds them (encrypted in its own DB) or assumes an instance/role, and every call your app makes is scoped by a DreamFactory API key tied to a role. Revocation is a key rotation in the DF admin UI, not a deploy.

// A thin service class keeps DF endpoints out of your controllers
class DfS3
{
    public function __construct(private PendingRequest $http) {}

    public function presign(string $bucket, string $key, int $ttl = 900): string
    {
        return $this->http->post("aws_s3/{$bucket}/{$key}", [
            'verb' => 'GET',
            'ttl'  => $ttl,
        ])->throw()->json('url');
    }
}

2. Presigned URLs for uploads — the pattern that saves the most Laravel code. Instead of proxying multipart uploads through your app (memory, timeouts, upload_max_filesize), ask DreamFactory to mint a presigned S3 URL and hand it to the browser. Your app stays out of the byte path entirely.

$url = $s3->presign('uploads', "invoices/{$uuid}.pdf", 600);
return response()->json(['upload_url' => $url]);

3. Queue and event offload. Use aws_sqs as a governed entry point for publishing jobs and let Laravel workers (or DreamFactory scripts) consume. This is genuinely useful when a second, non-Laravel system also needs to publish to the same queue — both go through DreamFactory and inherit the same auth and audit trail, rather than each holding IAM credentials.

Http::withHeaders(['X-DreamFactory-Api-Key' => config('services.df.key')])
    ->post(config('services.df.url').'/api/v2/aws_sqs/my-queue', [
        'MessageBody' => json_encode(['job' => 'reindex', 'id' => $id]),
    ])->throw();

4. Server-side scripting for composition. DreamFactory's V8/Node/PHP script hooks can call multiple AWS services in one endpoint — fan out an SES send plus an SQS enqueue plus an S3 archive in a single request. Reach for this instead of building a bespoke Laravel orchestrator when the logic is really just "call three AWS things in order." Keep the script in source control (it lives in DF's DB otherwise) and be aware you've now moved business logic out of your PHP test suite.

5. Two-tier access control. DreamFactory roles gate which endpoints an API key can reach; IAM gates what the underlying AWS identity can do. Layer them: one DF role per consumer (web app, mobile, internal batch), each mapped to a narrow IAM policy. Audit logs then tell you which consumer did what, which raw IAM CloudTrail won't.

6. Error normalization on the Laravel side. DreamFactory's error envelope is {"error": {"code": 404, "message": "...", "context": {...}}}. Laravel's ->throw() will produce a RequestException without useful body parsing, so wrap it once:

try {
    $response = $this->http->get(...);
} catch (RequestException $e) {
    throw new DfException(
        $e->response?->json('error.message') ?? $e->getMessage(),
        $e->response?->json('error.code') ?? 500,
    );
}

7. When not to use it from Laravel. If your app is the only consumer of S3 and you already have an IAM role attached to your compute, aws/aws-sdk-php directly is simpler and faster — one fewer network hop, one fewer failure domain. Adopt df-aws when you have multiple heterogeneous clients needing governed access, or when a compliance requirement mandates a central API gateway with per-consumer keys and audit.

Gotchas and Tips

Version coupling is the number one install failure. df-aws pins to dreamfactory/core major versions and to a specific aws/aws-sdk-php line. Installing it into a running DreamFactory instance often produces composer conflicts you resolve by pinning the platform, not the package. Check composer.json before upgrading either side, and never run composer update blind in a production DreamFactory install.

It will not boot in a vanilla Laravel app. The service provider extends DreamFactory's own package base class and depends on DreamFactory\Core\Contracts\* interfaces and DF's service container bindings. Attempting to composer require it into a normal Laravel project gets you a provider that either fails to resolve or silently does nothing. Treat it as platform infrastructure, and integrate over HTTP.

Secrets live in DreamFactory's database, not your .env. Don't mirror the AWS keys into your Laravel config for convenience — that defeats the entire point and creates two rotation surfaces. If you need the credentials in Laravel, question whether the gateway is buying you anything.

IAM: prefer instance roles over static keys. Static access keys in the DF admin UI are the default path and the wrong one on EC2/ECS/EKS. Confirm your platform version supports role assumption; if it doesn't, run the DF instance with an instance profile and leave the key fields blank.

Pagination is per-service and inconsistent. S3 ListObjectsV2 caps at 1000 keys; DynamoDB returns LastEvaluatedKey; SQS caps at 10 messages per receive. DreamFactory surfaces these as meta/resource envelopes but does not abstract them away. Write your own paginator per service rather than assuming a uniform next_page.

Large uploads through the API will bite you. Multipart-through-DreamFactory buffers more than you'd expect and hits PHP memory_limit/post_max_size on the DF container. Always use presigned URLs for anything over a few MB.

Clear the platform cache after config changes. DreamFactory caches service definitions and OpenAPI schemas; editing a service's credentials or endpoints in the admin UI won't reflect until you clear cache (php artisan cache:clear in the DF root, and config:clear after env changes). Symptom is "I changed the region and it still hits the old one."

Logs are on the other machine. Debug output goes to the DreamFactory instance's storage/logs/laravel.log, not your app's. Set APP_DEBUG=true on the DF instance, reproduce, then turn it off — production DF with debug on leaks stack traces and config.

Scripting is an extension point and a trap. Server-side scripts are powerful but stored in the database, outside your repo, and outside your test suite. If you go this route, commit the script bodies to version control and load them via a deployment step, otherwise a platform rebuild silently loses your business logic.

No community safety net. Two stars, zero dependents, and the meaningful support is vendor-side. The February 2026 release cadence suggests active maintenance, but budget for reading src/Services/ directly when docs are thin — you will be doing that often. Pin the exact version in composer.lock and test upgrades in staging.