Laravel packages can remove weeks of routine work, but every dependency also becomes part of the application you need to maintain. This article groups 20 useful packages by the problem they solve, explains the boundary of each one and shows how to choose a smaller set that will still make sense in several years.
01
The package list is not the architecture
Composer makes a package look almost free. One command adds the code, Laravel discovers the service provider and a polished feature can appear before lunch. The real cost arrives later, when the application depends on the package's data model, configuration, release cycle and assumptions.
That does not make packages a bad choice. Writing authentication tokens, payment webhooks, search indexing, audit trails or an admin panel from scratch would usually create more code to own and more places to make mistakes. A maintained package can give a team a tested starting point and let it spend time on the business rules that make the application different.
The useful question is not which twenty packages should be installed. It is which problem is expensive enough to justify a dependency, whether the package is healthy and how deeply the application should couple itself to that choice.
The list below is therefore a toolbox, not a starter kit. Some packages belong in almost every development workflow. Others only earn their place when the application has a particular operational need.
02
Twenty packages and the boundary of each one
This table gives the short version. The groups that follow explain where each package helps and where a team can accidentally expect too much from it.
Package names and compatibility change. Check the current documentation and Composer requirements against the PHP and Laravel versions used by the application before installing anything.
| Package | Best used for | Important boundary |
|---|---|---|
| Fruitcake Laravel Debugbar | Local request and query debugging | Keep it out of public production environments |
| Laravel Telescope | Detailed inspection of requests, jobs, logs and exceptions | Protect access and control stored data |
| Laravel Pint | Consistent PHP code formatting | Formatting does not prove correctness |
| Pest | Readable automated tests and test tooling | Check its current PHP requirement before upgrading |
| Larastan | Laravel-aware static analysis | Adopt stricter levels gradually on older code |
| Spatie Laravel Data | Typed data objects, validation and transformation | Avoid forcing every small value through a data class |
| Spatie Laravel Query Builder | Approved API filters, includes and sorting | Expose only fields and relations the API should allow |
| Spatie Laravel Media Library | Files and conversions attached to Eloquent models | Storage design and file security remain your responsibility |
| Filament | Admin panels, forms, tables and internal tools | Check that its interface model fits the product |
| Livewire | Dynamic server-driven Laravel interfaces | Use a client-heavy front end when the interaction genuinely needs one |
| Spatie Laravel Permission | Roles and permissions | A role matrix still needs business ownership and review |
| Spatie Laravel Activitylog | Recording model and user activity | Do not log secrets and define retention rules |
| Spatie Laravel Backup | Scheduled database and file backups | A backup is useful only after restore testing |
| Laravel Sanctum | SPA authentication and simple API tokens | It is not a full OAuth2 identity server |
| Laravel Socialite | OAuth login with supported providers | Provider changes and account linking still need handling |
| Laravel Horizon | Redis queue monitoring and worker configuration | It is specifically for Redis-backed queues |
| Laravel Pulse | High-level application performance and usage insight | It does not replace logs, tracing or alerting |
| Laravel Scout | Search across Eloquent models | Choose the simplest search engine that meets the need |
| Spatie Laravel Sitemap | Generating XML sitemaps | A sitemap supports SEO but cannot create useful content |
| Laravel Cashier Stripe | Stripe subscriptions and billing flows | Billing rules, reconciliation and webhook safety still matter |
03
Packages that improve the development loop
1. Fruitcake Laravel Debugbar puts request information, routes, views, queries, timing and memory beside the page being developed. The package was previously installed as barryvdh/laravel-debugbar and now uses fruitcake/laravel-debugbar. Its own documentation is very clear that it belongs in development, because its stored request information can expose sensitive details and the collectors add overhead.
2. Laravel Telescope provides a deeper view of requests, commands, jobs, exceptions, logs, mail, notifications, queries and other framework activity. It is useful when a fault crosses several parts of an application and a toolbar is too narrow. Telescope records a lot, so production use needs restricted access, deliberate pruning and care over which entries are stored.
3. Laravel Pint gives a project a consistent PHP style through a small command and a shared configuration. That reduces noisy code review comments and makes automated formatting easy to add to continuous integration. Pint can make a poor decision look tidy, so it belongs beside tests and review rather than in place of them.
4. Pest offers a concise test syntax on top of the PHP testing ecosystem, with additional support for architecture, browser and other forms of testing. Its current major version has a modern PHP requirement, which is exactly why package selection must begin with the application's real runtime rather than a fresh tutorial.
5. Larastan teaches PHPStan about Laravel's framework behaviour so it can find type problems that ordinary execution paths may not expose immediately. A mature application may produce a long list of findings on the first run. Starting at a realistic level, recording a baseline and tightening new code first is often more useful than demanding perfection in one pull request.
These five tools improve feedback. They do not change the application's product features, which makes them relatively easy to introduce and remove. They are a sensible place to begin when the goal is safer, faster delivery rather than another visible feature.
04
Packages that remove repeated application work
6. Spatie Laravel Data brings validation, typed data objects, API transformation and optional TypeScript definitions into one model. It can remove the drift between a form request, a transfer object and an API resource. The benefit is strongest at a real boundary, such as data entering from a request or leaving for a front end. Wrapping every tiny internal value can make simple code feel ceremonial.
7. Spatie Laravel Query Builder turns approved URL filters, includes, sorts and field selections into Eloquent queries. The word approved matters. A flexible API should still name exactly which fields and relationships a caller may request, otherwise convenience can become a data exposure or performance problem.
8. Spatie Laravel Media Library associates uploaded files with Eloquent models and can handle conversions and responsive images. It saves teams from rebuilding common file relationships and processing. It does not decide where sensitive documents may be stored, who may download them, how malware is checked or when files should be deleted.
9. Filament can accelerate an internal portal or administration area with forms, tables, actions, dashboards and resource screens. It is particularly useful when staff need to manage structured records and the interface does not need a completely bespoke interaction model. A public product with a distinctive user journey may still deserve purpose-built screens rather than an admin framework stretched beyond its strengths.
10. Livewire creates dynamic interfaces while much of the state and behaviour remains in PHP. It fits teams that want reactive forms, modals, tables and workflows without moving the whole application into a separate JavaScript architecture. For highly interactive offline experiences, complex client-side state or a product already built around a front-end framework, a dedicated client application may be clearer.
The shared lesson is that speed comes from choosing a package whose shape already resembles the work. If the team spends more time fighting the package than implementing the business rule, the apparent shortcut has become another layer to support.
05
Packages for access, evidence and recovery
11. Spatie Laravel Permission connects users to roles and permissions and integrates those permissions with Laravel's authorisation features. It solves the mechanics well. The business still needs to decide what an account manager, reviewer, administrator or customer should be allowed to do, and who reviews that access when responsibilities change.
12. Spatie Laravel Activitylog can record changes to models and actions performed by users. That is useful for support, accountability and regulated workflows, but an audit trail should be designed rather than switched on everywhere. Passwords, tokens, private document contents and other sensitive values should not be copied into a log merely because the package can observe them.
13. Spatie Laravel Backup can package application files and database dumps and monitor backup health. This is useful plumbing, not a complete recovery plan. Copies should be kept away from the live system, failures need alerts and the team needs to prove that a clean environment can restore the data within the time the business expects.
14. Laravel Sanctum supports first-party SPA authentication, mobile applications and simple API tokens. It is a good fit when the application controls both ends of the relationship and does not need the wider protocol of an OAuth2 server. Token abilities still need careful design and every endpoint still needs its own authorisation checks.
15. Laravel Socialite handles the OAuth flow for supported external login providers. It removes protocol work, but not the product decisions around linking an external identity to an existing customer, recovering access or responding when a provider changes the email address it returns.
No package can make an application secure by association. These tools provide reliable mechanisms. Security comes from combining them with clear access rules, safe configuration, dependency updates, monitoring and somebody who remains responsible for the whole path.
06
Packages for queues, monitoring, search and billing
16. Laravel Horizon provides a dashboard and configuration model for Redis-backed queues. It helps a team see throughput, failures, waiting jobs and worker behaviour. It earns its place when queued work matters to the operation. It does not support every queue driver, and the dashboard must not be left open to the internet.
17. Laravel Pulse provides a high-level view of application performance and usage, including slow requests, slow jobs, exceptions, queues and frequently used endpoints. It is a useful first view inside a Laravel application. A system with demanding operational requirements may still need central logs, distributed tracing, external uptime checks and alerts that work when the application itself is unhealthy.
18. Laravel Scout keeps searchable Eloquent models in sync with a search engine. The database engine can be enough for smaller applications, while Meilisearch, Typesense or Algolia can support more demanding search behaviour. Choose from the user's search needs and the volume of data, not from the assumption that every search box needs another service.
19. Spatie Laravel Sitemap can build XML sitemaps from application routes or discovered pages. This helps search engines find public content and makes dynamic sitemap generation easier. It cannot repair thin pages, duplicate content, poor titles, slow rendering or a site that does not answer the searcher's question.
20. Laravel Cashier Stripe wraps much of the recurring billing work around Stripe, including subscriptions, pricing, invoices and common payment flows. That can remove a large amount of integration code. The application still owns its plan rules, access decisions, webhook idempotency, failed-payment process, reconciliation and the experience a customer sees when billing changes.
Operational packages deserve a stronger review because they often sit close to money, customer access and production reliability. The question is not only whether the package works. It is whether the team can explain what happens when its external service, queue, search index or webhook does not.
07
Run eight checks before composer require
Start with compatibility. Read the package's current Composer requirements for PHP, Laravel and related extensions. A blog post may be current while the application is deliberately running an older supported stack.
Then inspect maintenance. Look at recent releases, open issues, upgrade notes, the security policy and whether the documentation matches the current major version. Download counts and stars show attention, not whether the package fits this application.
Read the licence and dependency tree. Run Composer's audit command against the lock file and keep it in continuous integration. An audit reports known advisories and abandoned packages, but a clean report is not proof that every dependency is safe.
Finally, design the exit. Keep core business rules in application code. Put package-specific calls behind a service or boundary when the package controls something commercially important. Record the decision and add tests around the behaviour the business depends on.
08
A shorter package list usually wins
The best Laravel package is the one that removes well-understood work without hiding responsibility. A team with a slow feedback loop may gain more from Pint, Pest and Larastan than from another user-facing library. A growing internal system may save months with Filament. A subscription product may sensibly rely on Cashier, while an application with no recurring billing should not install it merely because it appears on a list.
Choose one real problem. Compare the package with Laravel's built-in features and the cost of a small local implementation. Check its health, security and compatibility. Then decide where the application needs a boundary so the package remains a tool rather than becoming the architecture.
I build and support Laravel applications for established businesses, including portals, operational systems and integrations. If an application has gathered packages over several years or a new build needs a dependable starting stack, I can review the dependencies, risks and delivery choices before more code is committed.
Useful questions
Laravel package review checklist:
- Does the package solve a real and current problem?
- Could Laravel's built-in features solve it clearly enough?
- Does the current release support the application's PHP and Laravel versions?
- Are releases, issues, upgrade notes and security reporting still active?
- Is the licence acceptable for the application?
- Has the Composer lock file passed an audit?
- Will the package store sensitive data or expose a dashboard?
- Are backup, logging and retention settings deliberate?
- Can the core business rule be tested without the package?
- Is there a sensible route to upgrade or replace it later?
