Product Decisions This Supports
- Storage capacity planning and cost forecasting. By surfacing disk utilization (and, depending on configuration, object counts / usage breakdown) for S3-type disks directly inside Nova, the card turns an abstract cloud bill line into a weekly number the team can watch. That supports decisions like "do we need lifecycle policies on uploads?" or "is our media bucket growing faster than revenue?"
- Ops visibility as a product feature, not a side project. If your internal admin (Nova) is the operations surface for support and success teams, this card removes the need to ask engineering or open the AWS console to answer "how full is the bucket?" That's a small but real reduction in internal support load — a build-vs-buy call you can resolve for near-zero effort versus a custom card.
- Incident and quota triage. During a "uploads are failing" incident, the first questions are usually quota, permissions, or disk saturation. Having a per-disk view in the admin panel shortens the path from symptom to hypothesis, which affects how you scope runbooks and on-call expectations.
- Roadmap input for multi-tenant or media-heavy products. If you're evaluating per-tenant storage quotas, retention policies, or a "storage used" indicator in a customer-facing settings page, this package is a cheap prototype of the data shape you'd eventually need. It tells you what's easy to read from S3 and what isn't — useful before you commit engineering to a quota feature.
- De-risking vendor/admin tooling choices. It's a concrete data point on how extensible Nova is for your team. If a card this small covers your need, you can keep the admin panel as a low-investment internal tool rather than migrating to a heavier observability platform.
When to Consider This Package
Adopt or, more accurately, evaluate it when all of the following hold:
- You already run Laravel Nova and have at least one S3-compatible disk (AWS S3, MinIO, DigitalOcean Spaces, Wasabi) configured in
config/filesystems.php.
- Your team is comfortable reading and patching a small PHP card — treat this as a starting point, not a supported dependency.
- Storage growth is a recurring question for non-engineers (support, ops, finance) who already have Nova access.
- You want a half-day prototype of storage visibility before deciding whether to build a proper internal metrics pipeline.
Look elsewhere — or budget a from-scratch build — when any of these are true:
- Signals are thin. Zero stars, zero dependents, no release history in front of you. There's no community evidence of correctness or maintenance. Do not put this on a critical path without a code review and a plan to own it.
- You need alerting, history, or trends. A dashboard card reads a point-in-time value. If the actual requirement is "page someone when a bucket crosses 80%," you want CloudWatch alarms, S3 Storage Lens, or a scheduled job — not a Nova card.
- You need accuracy at scale. Enumerating objects to compute usage is slow and can be expensive on large buckets;
ListObjects-style counting is not a substitute for CloudWatch BucketSizeBytes or S3 Inventory reports. If numbers must be trustworthy for billing or quotas, use the cloud provider's own metrics.
- You're not on Nova, or you're on a Nova major version this card predates. Nova's card API has changed across versions; verify compatibility against your pinned version before planning around it.
- You need multi-cloud or cross-account rollups. A per-disk card won't aggregate across accounts, regions, or providers.
Practical adoption guidance: fork it into your own namespace, pin it, add a test around the disk-resolution logic (including missing/misconfigured disks — the failure mode you actually care about is a card that throws and breaks the whole dashboard), and confirm the read path uses credentials and permissions you're comfortable granting. s3:ListBucket and s3:GetBucketLocation are reasonable; anything broader needs justification.
How to Pitch It (Stakeholders)
For executives: This is a small, free add-on for our existing admin panel that shows how full our cloud storage buckets are, in the same place our team already works. It costs essentially nothing to try and answers a question we currently escalate to engineering. The caveat is that it's an unmaintained community component — I'd treat it as a template we own rather than a vendor product, and I would not rely on it for anything customer-facing or for billing-grade numbers. Recommendation: a timeboxed internal trial, with the expectation that we fork and maintain roughly a few hours a year.
For engineering: Scope is one Nova card that reads S3-type disks and displays usage. It's small enough to audit in an afternoon, which is what I'd ask for before we install it: confirm Nova version compatibility, confirm the disk-resolution behavior when a disk is missing or misconfigured, and confirm the IAM permissions it needs. Two risks to name up front — (1) point-in-time listing can be slow or costly on large buckets, so cap it or back it with CloudWatch BucketSizeBytes instead; (2) single-maintainer, zero-adoption project, so we vendor it rather than pull it from Packagist at deploy time. If the audit is clean, this is cheaper than building the card ourselves; if we need trends, alerting, or per-tenant breakdowns, we should build the real thing and skip this.
Ask: Approve a short evaluation spike (audit + install in staging) with a decision point: keep as an internal-only card, or replace with a CloudWatch/S3 Storage Lens-backed view if requirements grow beyond "how full is it right now."