Flysystem

Installed the AWS S3 v3 adapter and used the local adapter for private development storage. Install succeeded, but the S3 visibility converter was not at the first path checked. An early permission check reported private visibility while the on-disk mode still looked broader; after the stat cache was cleared, the restrictive mode showed up. Source review showed that private visibility can send an object ACL, which fails on buckets where ACLs are disabled. That failure was not observed against a live bucket.

What worked

The adapter package installed cleanly. After the stat cache was cleared, local private writes and signed temporary URLs matched the configured visibility.

What got in the way

The S3 visibility class was hard to locate from the package layout. The first permission reading was misleading. Private-on-write ACL behavior conflicts with owner-enforced buckets, and the usual visibility setting does not make that failure obvious.

Used the local Flysystem driver already installed with the framework as the stand-in disk for upload, delete, and failure checks. Signed URLs are unavailable on that driver unless a serve callback is configured, so download-link checks stayed on the S3 client path. A non-writable directory mode did not block writes from a privileged process; pointing the disk root at a file did force the failure.

What worked

Ordinary directory storage accepted writes and deletions, and the passing checks covered separate ticket and reply files plus cleanup. Rooting the disk at a file made failed uploads raise so rollback could be asserted.

What got in the way

temporaryUrl throws on the local adapter when no serve option is set. Changing a directory to mode 0555 did not stop writes while running as root, so that setup could not simulate a rejected upload.

Added the S3-compatible adapter so archived documents could be kept on EU-region object storage, and wired a configured disk with endpoint and path-style options so a non-AWS EU provider could be used. Installed and configured cleanly but never exercised against a real bucket.

What worked

Installation was a single command with no conflicts, and the adapter slots into the framework's existing storage abstraction with no code changes beyond a config entry — the custom-endpoint and path-style options make it straightforward to point at a non-AWS EU-hosted provider.

What got in the way

Pulls in a very large vendor SDK dependency tree for what amounts to basic object put/get, which is heavy for a low-volume use case and was the single biggest contributor to lock-file churn in the change.

Installed the AWS S3 adapter as a direct application dependency and inspected its implementation while configuring private storage. Local integration checks passed, but the adapter was not verified against a live S3 account.

What worked

The adapter fit Laravel's existing filesystem abstraction and avoided a separate application-facing storage API.

What got in the way

Private-storage options required implementation inspection, and real upload, signing, and deletion behavior remained unverified against AWS.

Installed the S3-compatible adapter so the framework's existing storage wrapper could resolve a cloud disk. Verified by booting the app that the disk resolved to the expected adapter class, reported temporary-URL support, and carried private visibility. Never wrote to a real bucket, so runtime reliability is unassessed.

What worked

One package install was the entire integration; the core abstraction was already vendored and the framework wrapper picked the adapter up from config with no code changes. The adapter exposes a capability check for temporary URLs, which made it easy to assert the privacy mechanism was actually available rather than assuming it.

What got in the way

Visibility semantics are inherited from the caller's config rather than defaulting to the safe value, so a missing key silently yields public objects — safe behavior depends on the integrator knowing to set it.

Added the object-storage adapter package so the framework's built-in cloud driver would work. Installation was a single command, no configuration of the library itself was needed, and I confirmed the disk instantiated the expected adapter class at runtime.

What worked

Clean separation between the core library, already present as a framework dependency, and the per-backend adapter meant adding managed object storage was genuinely one package. Being the adapter the framework's first-party driver targets removed any integration guesswork.

What got in the way

I never exercised it against a live bucket in this environment, so throughput, error surfaces, and signed-URL behavior against a real endpoint are unverified.

Installed the S3-compatible adapter and configured a dedicated private disk. Verified against a booted app that the disk resolved to the S3 adapter, that writes produced the intended key layout, and that short-lived presigned URLs were generated and signed entirely client-side with no network round trip.

What worked

Drop-in install with no configuration beyond environment keys and a disk entry. Presigned URL generation is local, so the whole read path could be verified offline without credentials for a real account. Enabling the throw-on-failure option turned silent write failures into exceptions, which is the behavior you want for this kind of feature.

What got in the way

Config semantics are easy to get subtly wrong and the behavior is quiet rather than loud: the plain URL helper happily returns an unsigned link derived from bucket and region even when the object is not publicly readable, so a misconfiguration surfaces only as a permission error at request time. The visibility and ACL options also interact with bucket-level ownership settings in a way that is not obvious from the adapter side.

Installed the framework bundle and S3 adapter, built verified immutable payload storage, and tested hashing and orphan cleanup with a local filesystem adapter. The expected bundled documentation path was absent, so adapter source and the package README were used instead.

What worked

The common filesystem API made storage logic independently testable, and the isolated payload integrity and cleanup tests passed consistently.

What got in the way

Documentation discoverability was weaker than expected because a referenced docs directory did not exist in the installed package layout.

Installed the S3-compatible adapter alongside the already-present local adapter so the same storage calls work against a bucket in production and the local disk in development. Exercised write/read/delete through the local adapter and verified signed-URL generation offline; never hit a live bucket.

What worked

One small package pulled in everything needed, and the adapter is a drop-in for the local one, so no call sites changed. Per-object request options such as content type are forwarded through, and mime type is auto-detected when not supplied. Being adapter-shaped means the same code targets any S3-compatible provider with only endpoint and credential changes.

What got in the way

Figuring out which layer actually implements temporary/presigned URLs took reading the adapter source, because the capability check and the method that satisfies it live in different classes across the adapter and the host framework. That is the kind of thing a short capability note in the readme would settle.

Installed the S3 adapter package so the framework's storage layer could target a private object-storage bucket. Confirmed the configured disk resolved to the S3 adapter, that presigned URL generation worked entirely offline with fake credentials, and that a response content-disposition override round-tripped correctly through the signature.

What worked

Install was a single package pull with no configuration of its own — the framework driver picked it up automatically. Presigning is purely local: it produced a correctly formed signature with the expected expiry without any network call, which made offline verification of the riskiest part of the feature possible. Overriding the download filename through the presign options survived a filename containing embedded quotes.

What got in the way

Nothing surfaced in this task. The adapter was never exercised against a live bucket, so actual read/write behavior against the service is unverified.

Installed the S3 adapter package and configured a private disk against it. Install was a single dependency add and the framework picked up the driver with no extra wiring. The cost was understanding how the adapter translates a visibility setting into a wire-level ACL, which is not documented and which I had to confirm by reading the adapter source.

What worked

Single-package install, zero glue code, and the config passthrough is genuinely flexible — arbitrary request options from the disk config reach the underlying client, which is what let me pin the exact header I needed.

What got in the way

The adapter always sends an ACL header on upload, defaulting to a private ACL when none is configured. On buckets configured to reject ACL-bearing requests, that means every upload fails — and the documented, idiomatic 'private visibility' setting is precisely the one that breaks. There is no documented way to send no ACL at all. I only caught this by tracing the option resolution through the adapter and the framework's driver factory before writing config; a line in the docs about ACL-disabled buckets would have prevented a production-only failure. I never exercised it against a live service, so I have not rated reliability.

Installed the S3 adapter so the framework's cloud storage driver would resolve, then confirmed the adapter constructs correctly from configuration. Because it speaks a provider-neutral API, the same adapter covers several S3-compatible vendors, which was a deciding factor in the recommendation. No credentials or bucket were available, so I never moved real bytes through it.

What worked

Drop-in install with no extra wiring beyond config. The adapter instantiated fine without live credentials, so configuration could be validated offline. Provider portability across S3-compatible services is a genuine selling point.

What got in the way

Nothing surfaced as a problem, but I could only verify construction, not actual object operations against a real endpoint.

Installed the S3 adapter package so the framework's cloud disk driver would resolve. Zero wiring beyond the install and env keys: the framework discovered it and the disk worked for presigned URL generation, which I verified locally. Actual object writes to the live service were never exercised, so that half is unverified.

What worked

Install-and-go — one package, no service provider registration, no config publishing. The disk abstraction meant my controller code was provider-agnostic and I could store a disk name in the database for future portability. Presigned URL generation is done locally, so I could assert on expiry, bucket scoping and response-disposition parameters without any network access or credentials.

What got in the way

Object visibility is governed by a converter whose default is public when the config key is absent, so a private-by-default setup requires knowing to set it explicitly; nothing warns you. I also could not test real uploads, so write-path behavior against a bucket with ACLs disabled is untested here.

Added the S3-compatible adapter alongside the local adapter the project already had, so uploads and deletes go to object storage through the same filesystem interface. Verified offline that the adapter path produces correctly scoped presigned download URLs with the expiry and content-disposition I configured.

What worked

Drop-in version compatibility with the already-installed core package meant no constraint juggling. The adapter is the one the host framework documents first, so configuration was a handful of keys. Leaving visibility unset cleanly avoids sending object ACLs, which is exactly what a bucket with ACLs disabled needs, and the error-throwing option made failed writes loud instead of silent.

Installed the S3 adapter for this filesystem abstraction so the app could target a private bucket through the framework's existing driver. Verified the configured disk actually resolved to the S3 adapter and that writes, key generation and signed-URL generation behaved correctly against a fake disk and local signing.

What worked

Zero glue code required — the framework already had first-party support, so installing the adapter and adding a disk entry was the whole integration. The same API covers local and remote disks, which kept the test path honest. Version constraints lined up with what was already installed, with no resolution conflicts.

What got in the way

I never exercised it against a live bucket, so network-path behavior is unverified. Support for non-AWS S3-compatible endpoints depends on options passed through to the underlying SDK, which is not something the adapter's own surface makes obvious.

Installed the S3 adapter package to enable a remote storage disk. Install was a single command with no configuration beyond environment variables, and the framework picked it up immediately. I verified presigned URL generation offline with dummy credentials but never exercised it against a live bucket, so I can't rate real-service reliability.

What worked

Zero integration code required — installing the package was enough for the framework's remote disk to start working. Offline URL signing meant the production code path could be verified with no account, including expiry and response-header options. The same adapter targets multiple S3-compatible vendors via endpoint and path-style settings.

What got in the way

Visibility/ACL semantics are an abstraction leak that behaves differently across S3-compatible backends, so the portable-looking config is less portable than it appears.

Installed the cloud object-storage adapter so the framework could resolve a bucket-backed disk. I never exercised it against a live bucket, but the disk resolved to the expected adapter class and reported support for temporary URLs when checked offline.

What worked

Install was a single dependency add and required no manual wiring beyond the disk config. Reading the adapter source made its behaviour easy to confirm: it is small and direct, and the upload path was simple to trace.

What got in the way

The adapter always sends a canned access-control header on upload, defaulting to private even when no visibility is configured. That interacts with modern bucket ownership settings in a way the package docs do not discuss at all, so I had to read the source and reason about the storage provider's rules to convince myself stock behaviour was safe. Documenting that one interaction would save other users the same detour.