- What is achyutn/filament-storage-monitor used for?
- Filament Storage Monitor is a Filament panel plugin that adds a dashboard widget for tracking server disk usage. It supports multiple configured disks or partitions, custom labels, colors, icons, and health-based coloring so filling disks are easier to spot. It is built for Filament panels only, not for Nova, Backpack, or standalone SPAs.
- How do I install and register filament-storage-monitor in a Laravel Filament panel?
- Install it with composer require achyutn/filament-storage-monitor, then register FilamentStorageMonitor inside your panel's plugins array. Once at least one disk is configured with addDisk(), add(Disk::make(...)), or laravelDisk(), the plugin auto-registers the dashboard widget. You can chain widget options such as columnSpan(), sort(), lazy(), and visible() on the plugin.
- Which PHP and Filament versions does Filament Storage Monitor support?
- The package requires PHP 8.2 or newer and supports Filament 4.x and 5.x. Check your composer.json and CI matrix to confirm those constraints before adding it. Laravel filesystem disks can be reused through laravelDisk(), so local-driver disks usually need no extra configuration.
- How do I monitor multiple disks or partitions with Filament Storage Monitor?
- Add each partition or path with addDisk(path: ..., label: ...), with the Disk DTO via add(), or from Laravel filesystem config using laravelDisk(name: ...). Each disk can have its own label, color, icon, and visibility settings. Note that measurement is partition-scoped, so two paths on the same mount will report identical total and free space.
- How does laravelDisk() work with Laravel filesystem configuration?
- laravelDisk(name: 'public', label: 'Media Storage') resolves a disk from config/filesystems.php and reuses its local driver path. This is the lowest-friction option for existing Laravel disks and avoids duplicating path configuration. Confirm the disk is locally mounted and readable by the PHP process running Filament.
- Can Filament Storage Monitor show per-directory or per-tenant disk usage?
- Today the widget reports partition-level usage rather than per-directory or per-tenant quota accounting. Adding nested paths on the same mount does not produce separate directory usage numbers, and per-tenant or per-bucket quota use cases are not supported. Treat per-directory and per-tenant reporting as roadmap items and verify against your actual requirements before adopting it.
- How does caching affect the disk usage widget and how stale can the numbers be?
- Since v1.4.2 the widget uses an internal cache layer, so it renders last-known measurements rather than running a filesystem stat on every render. The cache TTL and failure-caching behavior are not clearly documented, so verify freshness and error handling in staging. A cache flush can visibly reset the widget, and with the array cache store caching is effectively per-request.
- How do I customize labels, colors, icons, and health-based coloring in the storage widget?
- Health-aware coloring reacts to usage thresholds, and you can set per-disk colors, icons, and labels through the fluent API or the Disk DTO. The exact threshold behavior should be reviewed in the package source or tested against your target disks. Use visible() if a disk card should only appear for certain users or environments.
- Does filament-storage-monitor require migrations or queues, and how should I test it?
- The package adds no migrations, queues, or scheduler dependency, so deploy-order coupling is minimal. It does depend on a working cache store in v1.4.2 and later, so confirm behavior when Redis, Memcached, or file cache is unavailable. For testing, configure disks that exist in the test environment and account for the array cache making caching inert.
- Can I use Filament Storage Monitor outside Filament, and what should I check before upgrading?
- It will not work outside Filament panels; for Nova, Backpack, Livewire-only dashboards, or SPAs you need a different solution or a custom widget. If you are upgrading from v1.4.0 or earlier, re-check dashboards because cache key scoping and cached metric casting fixes in v1.4.2 can change displayed values. Re-take screenshots or runbook baselines after upgrading.