Ploi Dashboard Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling. This package is essentially a pre-built Filament admin panel over the Ploi API. Adopting it converts a "do we spend 4–8 dev-weeks building a server/site management UI" decision into a "do we install a dependency" decision. That is a strong trade for internal tooling where differentiation is zero.
• Embedding infrastructure operations into the product surface. Because it ships as a Filament plugin, server/site management can live inside the same admin panel your team (or your customers) already use, rather than in a separate tool with a separate login. That supports decisions like "should agencies be able to manage client hosting without leaving our app?"
• Roadmap: self-serve hosting/agency tier. If the roadmap includes letting customers or agency partners provision and inspect servers, sites, or deployments, this package is a credible accelerant for the visibility layer — provided the underlying Ploi account model matches your tenancy model.
• Platform commitment: Filament as your admin framework. v2.1.1 adds Filament 5 support, which makes the Filament bet safer and extends the package's usable life. If Filament is your admin stack, this raises the package from "risky side project" to "plausible dependency."
• Use cases that fit well: agencies managing many client WordPress/Laravel sites on Ploi; internal DevOps dashboards; support teams needing read access to server/site status without Ploi seats; consolidating "where is this site hosted and is it up" into the product.
• Use cases that do not fit: anything where the panel is customer-facing and brand-critical, anything requiring write operations the package doesn't expose, and any environment where Ploi is not the hosting provider.

When to Consider This Package

Adopt when all of the following hold:

• You already run (or are committing to) Ploi for server provisioning and site management. The package is an adapter, not a replacement — it has no value against Forge, Laravel Cloud, or raw AWS.
• Your admin surface is Filament 3, 4, or 5. v2.1.1's headline change is Filament 5 compatibility, so the dependency no longer pins you to an older major.
• Your need is visibility and light operations — listing servers, sites, status — rather than opinionated deploy pipelines, custom runbooks, or approval workflows.
• You can accept a community-maintained, single-maintainer package with no SLA. Mitigate with a fork-and-own plan; the surface area is small enough that forking is realistic.
• You are comfortable that the panel sits in front of infrastructure credentials. Scope the Ploi API token narrowly, keep the panel behind strong authz, and treat it as an internal tool unless you've audited the exposure.

Look elsewhere when:

• You need guaranteed maintenance, security response times, or vendor support — this is dependabot-and-volunteers territory.
• You need write operations (create servers, trigger deploys with guardrails) beyond what the package exposes; you'll end up building anyway, so build it deliberately.
• You are not on Filament, or you're mid-migration between Filament majors — wait until your admin stack settles.
• Your multi-tenant model requires per-customer isolation of infrastructure views; verify the package's assumptions before promising this to customers.

How to Pitch It (Stakeholders)

To executives: This is a small, free Laravel plugin that gives us a ready-made dashboard for the servers and sites we run on Ploi — essentially a control panel we would otherwise spend weeks building. The latest release (v2.1.1) is a maintenance release whose meaningful change is support for Filament 5, the current version of our admin framework. That matters because it means the plugin isn't stranded on an older framework version, so adopting it doesn't create an upgrade liability later. Cost is near zero; the risk is that it's community-maintained by a small number of contributors, so we should treat it as a forkable starting point rather than a vendor dependency. Recommendation: pilot it internally for ops visibility, with a small budget reserved to fork and maintain if we come to rely on it.

To engineering: v2.1.1 is almost entirely dependabot bumps plus one substantive PR — Filament 5 support, contributed by a first-time contributor. Concretely: the Filament constraint is now widened, so it drops into a Filament 5 panel without version pinning gymnastics, and it also remains usable on earlier majors. There are no breaking changes, no deprecations, and no API surface changes called out. Two things to weigh before adoption: (1) the release cadence is automated rather than feature-driven, which tells you the maintainer's investment is low — plan for a fork if this becomes load-bearing; (2) the package is a thin Filament layer over the Ploi API, so review the authz boundary and token scoping before it goes anywhere near production credentials. Low-risk trial, small surface area, easy to replace.