- What is qubeek/nova-storage-info-card?
- It is a Laravel Nova card that surfaces storage information for your application's S3-type disks inside the Nova admin panel. The package is a presentation-layer widget only: one Nova Card class plus a compiled Vue component, registered from NovaServiceProvider::cards(). It adds no domain logic, no middleware, no persistence, and no migrations, so its architectural footprint is minimal.
- Which Laravel Nova versions does qubeek/nova-storage-info-card support?
- The package metadata does not include a compatibility matrix, so there is no documented supported Nova major. Nova cards depend on Nova's internal Vue component API, which has changed across Nova 3, Nova 4 and Nova 5, so assume tight coupling to whatever major was current at the author's last commit. Check the last commit date and test against your Nova version before installing, and pin the version in composer.json.
- How do I install qubeek/nova-storage-info-card?
- Install it with Composer using composer require qubeek/nova-storage-info-card, then register the card in the cards() method of your NovaServiceProvider. The package configuration is publishable, and there are no migrations or extra service-provider bootstrapping beyond the card registration. Commit the lockfile after install because this is a small single-vendor package.
- How do I configure which disk the storage info card monitors?
- Publish the package config and point it at a disk already declared in config/filesystems.php. Working AWS credentials for that disk must exist for the card to return real numbers. Keep the disk definition in your app's filesystems config rather than duplicating credentials in the card config.
- How does it calculate S3 bucket size, object listing or CloudWatch?
- The supplied metadata does not say, and the answer matters a lot. One implementation enumerates objects via ListObjectsV2, where cost and latency scale linearly with object count and pagination over large buckets can take minutes. The other reads CloudWatch BucketSizeBytes, which lags by up to roughly 24 hours and requires cloudwatch:GetMetricStatistics in the correct region. Read the source before installing so you know whether this is a harmless tile or a dashboard-slowing, billable operation.
- What IAM permissions does qubeek/nova-storage-info-card require?
- Either data-source mode needs read permissions your application may not currently hold: bucket listing and/or CloudWatch metric reads. The exact action set is not documented in the provided metadata, so do an explicit least-privilege review instead of inheriting the disk's existing policy. Scope the policy to the single bucket and region you are monitoring.
- Does qubeek/nova-storage-info-card work with local disks or only S3?
- The package overview describes it as a card for controlling S3-type disks, while the short blurb claims it works for local or remote disks, so the docs are inconsistent. Verify in the source which filesystem drivers actually produce usable numbers before relying on it for a local disk. A local path would typically be measured with filesystem space functions rather than the S3 APIs.
- Will this Nova card slow down my dashboard?
- That depends entirely on the data source and whether results are cached. The metadata does not confirm any caching or TTL, and if the card enumerates a large bucket on every render it can slow the dashboard and generate billable API calls. Look for a cache TTL in the source, and avoid placing it on a dashboard that is loaded frequently by many users.
- What happens if the S3 credentials or permissions are wrong?
- This is not documented, and it is the failure mode to test first. A Nova card renders as part of the dashboard, so an unhandled exception from a failed ListObjectsV2 call or a CloudWatch permission error can break the card's render or the dashboard around it. Exercise it in staging with credentials that deliberately lack the required permissions and confirm it degrades gracefully.
- Is qubeek/nova-storage-info-card maintained and safe for production?
- The validation signals are effectively absent: zero stars, zero dependents, and a score of zero, so treat it as a readable code sample rather than a supported dependency. The realistic comparison is not adopt versus build from scratch but review about 200 lines versus write about 200 lines, which caps the value of taking on an unvetted package. If you do adopt it, pin the version, read the source first, commit the lockfile, and keep CloudWatch alarms as your real capacity alerting rather than replacing them with this tile.