70%+ of developers spend between 5 and 30 minutes just to determine if a plugin is healthy enough to install
This is "Dependency Anxiety." It’s the recurring cost we pay every time we search for a package or audit our composer.json. Is this package abandoned? Does it support PHP 8.5? Are the tests passing? Multiply those 30 minutes by every package in your stack, and the productivity loss is massive.
To solve this, I built Laraplugins.io, an automated intelligence tool designed to do that vetting for you and display it to you so you can get a pretty good idea of the health status in seconds.
The Architecture: Built for Speed and Scale
As a DevOps and developers, I wanted the infrastructure to be as robust as the data it serves. I designed a high-performance architecture capable of handling heavy traffic on a single multi-site VPS running over 30 projects and nearly 100 Docker containers. here more info if curious about my laravel stack.
The Stack
The application runs on a modern, containerized stack optimized for concurrency and low latency:
- Runtime: Laravel Octane with FrankenPHP
- Routing: Traefik Reverse Proxy
- Caching: Redis & Cloudflare CDN
- Orchestration: Docker Compose
Request Lifecycle
The flow is designed to minimize hit-rate on the application server:
User -> Cloudflare CDN -> Traefik -> FrankenPHP (Octane) -> Redis
- Edge Caching: Public pages are cached by Cloudflare for 2 hours. This drastically reduces server load by serving static content directly from the edge.
- Efficient Routing: When traffic reaches my VPS, Traefik handles the routing. It ensures fast, reliable directing of requests across the dozens of micro-services and sites running in parallel.
- In-Memory Bootstrapping: Finally, Laravel Octane and FrankenPHP take over. Because the application stays booted in memory, we eliminate the traditional PHP-FPM overhead, ensuring responses are nearly instantaneous.
The "Health Score" Algorithm
The core of Laraplugins.io is the Health Score. It’s not a magic number, but an aggregate of about 10 key signals that determine a package's viability.
1. Update Recency
This is the baseline. Developers need active maintenance. I track the last commit date and release history to ensure you aren't installing abandonware.
2. Version Compatibility
I rigorously check composer.json constraints to verify active support for modern Laravel and PHP versions. If a package is stuck on Laravel 9, you need to know.
3. The "Archived" Penalty
If a project is archived on GitHub, we apply a heavy penalty. This marks a definitive end of life for the package, and it should generally be avoided for new projects.
4. Normalized Download Stats
We monitor download counts, but we’ve intentionally reduced their weight in the final score. We want to highlight quality, not just popularity. This ensures new, high-quality plugins aren't unfairly penalized just because they haven't been around for years.
5. Best Practices & Quality
Finally, we scan for indicators of a mature engineering culture: presence of CI/CD pipelines, active test suites, and valid licenses.
Feedback Welcome
The Health Score is currently in beta. I’m building this for the community, so I want to hear from you. What signals do you look for before composer require-ing a new package?
Let me know your thoughts, and check out the launch on product hunt please
