Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Flysystem Aws S3 V3 Minio Laravel Package

coraxster/flysystem-aws-s3-v3-minio

A Flysystem AWS S3 v3 adapter built for MinIO object storage. Use familiar S3 APIs against self-hosted MinIO buckets in Laravel and PHP projects, with straightforward configuration for custom endpoints, credentials, and bucket paths.

Deep Wiki
Context7

Product Decisions This Supports

  • Storage backend strategy — build vs. buy vs. self-host. Whether to support S3-compatible object storage beyond AWS (MinIO on-prem, in-VPC, or air-gapped) as a first-class option in the platform, rather than treating AWS S3 as the only supported object store.
  • Data residency and sovereign/regulated deployment roadmap. MinIO support is the enabling technical detail behind commitments like "customer data stays in your datacenter," "no external egress," or on-prem/private-cloud SKUs. This is a sales-enablement and compliance decision as much as an engineering one.
  • Vendor lock-in posture. Routing storage through the Flysystem abstraction (rather than AWS-specific SDK calls scattered through the codebase) keeps the storage layer portable. This is a durable architectural decision; the package itself is only the last mile of it.
  • Environment parity and cost. Standardizing dev/test/staging on MinIO while production runs on S3 lets teams avoid paying for non-production buckets and exercise the same code path everywhere. This is a meaningful line item for teams with many ephemeral environments.
  • Migration sequencing. Whether "move uploads from local disk to object storage" can ship as a config-only change (Laravel filesystem disk swap) or requires application refactoring. This determines whether a migration is a one-sprint task or a quarter.
  • What this package does not decide. Its actual scope is narrow: custom endpoint + path-style URL + credentials wiring on top of league/flysystem-aws-s3-v3. That combination is already a native capability of Laravel's S3 driver (endpoint, use_path_style_endpoint). So the product decision it supports is "do we need MinIO?" — not "should we adopt this package?"

When to Consider This Package

Consider it only when all of the following hold:

  • You are on a legacy stack: Laravel 5.x–8.x with Flysystem 1.x. The last release was 2017-09-26, which predates Flysystem 2/3 and modern Laravel's filesystem driver; expect install and API friction on anything current.
  • You already depend on this adapter in production and are not planning an upgrade in the near term — in which case the decision is "tolerate and freeze," not "adopt."
  • Your team has accepted bus-factor and patching risk: 25 stars, no visible recent maintenance, and a dependency that sits directly in the credential-handling and file-upload path. That is a security-surface decision, not just a convenience decision.

Look elsewhere — specifically, use Laravel's built-in S3 driver with league/flysystem-aws-s3-v3 directly — when:

  • You are on Laravel 9+, where MinIO works out of the box with: 'driver' => 's3', 'endpoint' => env('AWS_ENDPOINT'), 'use_path_style_endpoint' => true. No third-party adapter required; one less unmaintained dependency in the upload path.
  • You need active security patching, PHP 8.x support, or compatibility with current AWS SDK versions — none of which a 2017 release can credibly promise.
  • You need MinIO administration capabilities (bucket policies, lifecycle, replication, IAM) rather than plain object CRUD; the official MinIO client or server-side tooling is the right tool.
  • You are evaluating this for new code. Adopting an eight-year-dormant adapter for a new feature is a hard no; the capability is available natively and the maintenance burden is strictly additive.

How to Pitch It (Stakeholders)

To executives: We need a storage strategy that doesn't hard-wire us to AWS. Supporting S3-compatible object storage — MinIO for on-prem, private-cloud, and regulated customers — unlocks deals and SKUs we currently can't serve, and keeps our data layer portable if cloud costs or vendor terms shift. That strategic direction is sound and worth funding. The specific package in front of us, however, is not the way to get there: it was last released in 2017, has ~25 stars and no visible maintainer, and duplicates functionality Laravel now ships natively. Recommendation: pursue the MinIO capability, decline this package — we get the same outcome with zero added dependency risk.

To engineering: The requirement is real and cheap to satisfy. On current Laravel, MinIO is a config change: point the s3 disk at a custom endpoint, set use_path_style_endpoint => true, drop in credentials, done — using the officially maintained league/flysystem-aws-s3-v3 we already trust. This package wraps exactly that, but pins us to a 2017-era Flysystem/SDK combination, sits in the credential and upload path, and gives us no upgrade path. For any legacy service genuinely stuck on Flysystem 1.x, we'll pin it, isolate it, and put it on the deprecation list rather than spread it further. Net: adopt the pattern, not the package.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
mehedimi/laravel-amp-mail
happones/laravel-vue-i18n-generator
jwerd/inertia-table
siberfx/flysystem-wasabi
hollyit/token-replace
ippanelcom/laravel-sdk
adachsoft/changelog-linter
adachsoft/collection
payerurl/telegrambot-crypto-payment-instant-payout
dskripchenko/laravel-hybrid-search
riorizkyrainey/lara-ced
mehedimi/static-vel
zharp/zharp
nonsapiens/bigquery-model-sync
lgu-bayambang-ict-office/lgu-laravel-development-standards
andydefer/laravel-support
se7enxweb/flysystem
lampwick/laravel
jeslage/statamic-emojis
micahdshackelford/rmap-laravel