Flysystem Openstack Swift Laravel Package

Product Decisions This Supports

Storage backend strategy (build vs. buy vs. wire up). This package is a thin Flysystem v3 adapter that lets Laravel's Storage facade write to OpenStack Swift. For a PM, its real value is that it turns "support private-cloud object storage" from a custom engineering project into a configuration item. That is a scoping decision, not a code decision: it's the difference between a 3–5 day spike and a multi-sprint integration.

Enterprise / sovereign-cloud deal unblocking. Swift is the object layer of choice in OpenStack-based private clouds — telcos, government, EU data-residency hosting, and on-prem enterprise deployments. If a prospect or existing account says "our files must live in our Swift cluster," this adapter is the cheapest path to a "yes." Roadmap framing: "Private cloud / data residency support" as a sellable checkbox, powered by ~200 lines of adapter rather than a bespoke driver.

Multi-cloud and exit-risk posture. A filesystem abstraction that already speaks S3, GCS, Azure, FTP, and now Swift means storage vendor choice is a config change, not a rewrite. Useful when negotiating with a hosting provider or when a customer's cloud changes mid-contract.

Migration and portability features. Bulk import/export tooling, backup targets, and media archival jobs can point at Swift without new code. Relevant if you're onboarding a customer migrating off Swift — read from Swift, write to S3, retire the cluster.

Roadmap triage signal. 43 stars, 0 dependents, single maintainer, last release Feb 2023. Internal score is high (0.985) but the opportunity score (35.47) is low — the package is well-built for a market that barely exists. Treat it as a capability enabler, not a product bet, and don't plan a roadmap pillar on top of it.

Adoption decision to make explicitly: depend on it, fork it, or absorb it. With 0 dependents and a stale release cadence, "depend on it" is only defensible if you're willing to own a fork the day it breaks. Budget for that up front — it's a one-line line item in planning, and it prevents a nasty surprise.

When to Consider This Package

Adopt when:

• You have a real, named OpenStack Swift endpoint — an internal private cloud, a customer's on-prem cluster, or a Swift-based host. Not "we might need this someday."
• The app is Laravel and already uses Storage / Flysystem. The integration cost is a driver registration plus credentials in config/filesystems.php.
• You need native Swift API semantics (containers, large-object manifests, temp URLs, metadata) rather than an S3 shim.
• You can accept MIT, no warranty, effectively one maintainer, and have someone who can read the adapter and patch it.
• You want to avoid writing and maintaining an adapter yourself — vendor it, pin the commit, and move on.

Verify before committing:

• Flysystem major-version compatibility. Last release Feb 2023 predates later Laravel/Flysystem bumps. Confirm it works with your Laravel and league/flysystem versions; run your own contract tests against a real Swift endpoint.
• Feature coverage vs. what your product actually does. Test the operations you ship: streaming downloads, multipart/large uploads, presigned/temporary URLs, directory listing, metadata, and any visibility/permission behaviour. Adapters often cover the happy path and quietly miss the rest.
• Credential and auth model. Swift auth (keystone v2/v3, tenant/project scoping) is more involved than an S3 key pair; confirm it matches your customer's setup docs and your secrets management.

Look elsewhere when:

• Your storage is AWS S3, GCS, Azure, or any S3-compatible endpoint — use the first-party or widely-adopted adapters; far better support and community.
• The Swift cluster exposes an S3-compatible gateway and you don't need native Swift features — league/flysystem-aws-s3-v3 against that endpoint is a lower-risk dependency and avoids the abandoned-package problem entirely.
• You need filesystem semantics Swift doesn't provide (POSIX-like, atomic rename, locking) — object storage will fight you regardless of adapter.
• You need guaranteed vendor support, SLAs, or security patching — this is not that; budget a fork.
• The requirement is speculative ("some enterprise customers like on-prem"). Build the abstraction seam, defer the driver until a deal is in play.

How to Pitch It (Stakeholders)

For executives — one paragraph. We can support customers who require their files to stay on their own private cloud, for roughly a day of engineering instead of a project. This package is an MIT-licensed connector that plugs OpenStack Swift storage into Laravel's existing file-handling layer, so it's a configuration change rather than new infrastructure. It removes a common blocker in enterprise, government, and EU data-residency deals at near-zero cost. The caveat is honest and small: the package is maintained by a single developer with no recent release, so we should treat it as code we own — pin it, test it, and be ready to fork it if needed. That's a few days of diligence, not a risk to the roadmap.

For engineering — the ask. Register this as a Flysystem disk driver behind the Storage facade, pin it to a specific commit, and wrap it in contract tests against a real Swift endpoint covering the operations we actually ship (upload, stream, temp URL, listing, large objects). Confirm Flysystem/Laravel version compatibility and the Keystone auth flow before we commit. If the package fails our tests, the fallback is either (a) fork and maintain the ~200-line adapter in-house, or (b) use Swift's S3 gateway with the AWS adapter. Either way, the abstraction seam is what we're buying; the driver itself is replaceable.

Framing to avoid: don't sell this as a feature. Sell it as "we can say yes to a storage requirement we'd otherwise decline" — and let the deal size, not the package's 43 stars, decide whether it's worth the maintenance commitment.