Filament Deploy Indicator Laravel Package

Getting Started

• Install with composer require arnautdev/filament-deploy-indicator (check the package's composer.json constraints against your Filament major version — v3 vs v4 are not interchangeable).
• Publish the config: php artisan vendor:publish --tag="filament-deploy-indicator-config". This is the single most important file — almost all behavior (what is shown, where, and whether DevTools output is included) is driven from here.
• Register the plugin on the panel(s) you want it on in your PanelProvider:

  ->plugin(DeployIndicatorPlugin::make())
  

• First use case: drop the indicator onto an admin/staging panel so operators can see the current deploy context (environment, commit, deploy time) at a glance without SSH-ing into the server. Start by getting it rendering on a single non-production panel, confirm the data source is populated, then decide whether to expose it on production panels.

Implementation Patterns

• Single-panel, single-widget. Register the plugin on one panel and let the default config render the indicator. This is the lowest-risk integration and the right starting point before customizing.
• Environment-gated display. Wrap registration so the indicator only appears where it makes sense, e.g. only on staging panels or only for users with a specific gate/permission. This avoids leaking commit hashes or deploy metadata to end users on production.
• CI/CD-driven metadata. The useful signal comes from your deploy pipeline writing commit SHA / build number / deploy timestamp where the indicator expects it (env vars or a cached file). Treat the indicator as a view over data your pipeline produces, not as something that shells out to git on every admin page load.
• Config-driven customization. Prefer editing the published config over subclassing the plugin — toggles like enabling/disabling DevTools output, choosing which fields to surface, and widget placement are all config concerns. Re-publish or diff the config after upgrades to pick up new keys.
• Multi-panel setups. If you run separate admin and operator panels, register the plugin explicitly per panel and use separate config values rather than relying on global defaults, so you can show richer deploy info internally and minimal (or no) info externally.

Gotchas and Tips

• v1.3.2 changed the DevTools default. The release disables DevTools in the deploy indicator config. If your existing published config previously surfaced DevTools output, this default flip may silently hide information you relied on — re-enable it explicitly in your config if needed. Because published configs are not automatically updated, verify whether you're picking up the new default or still running the old published file.
• Config caching bites. After publishing or editing the config, run php artisan config:clear (and remember config:cache in production). A stale cached config is the most common reason "the setting didn't change anything."
• Don't call expensive sources per request. Avoid patterns that invoke git, read files, or hit the filesystem on every panel render. Compute deploy metadata at deploy time (pipeline writes it) or cache it; the widget should read a cheap value.
• Version pinning. Pin the package version in composer.json and read the changelog on minors — this project is on 1.x with patch-level bugfixes, so behavior-affecting changes are more likely in minors than patches.
• Visibility is a security concern, not just UX. Deploy indicators expose environment names, commit hashes, and timestamps. Gate the widget behind authorization and keep it off public-facing panels by default.
• Config is the extension point. Before forking or subclassing, check whether the config exposes the toggle you need; if a genuinely missing knob blocks you, prefer opening an issue over patching vendor code so upgrades stay clean.
• Verify after upgrade. After bumping to 1.3.2, load the panel on staging, confirm the indicator renders, and confirm the DevTools setting matches your intent (given the default change).