You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A curated list of Laravel 13.x features, official packages, community packages, observability tooling, self-hosted infra patterns, YouTube channels, and websites. Inspired by awesome-php and other awesome lists.
No mainstream Laravel package — integrate via their REST API directly
Reality check: the "Indian payment gateway" Laravel package space is fragmented and thinly maintained — indipay has had several forks/rewrites over the years (nickatwork → dbhosale → softon → ineffablesam → rushabhmishrarmz), each essentially the same wrapper. For anything beyond Razorpay (which has solid first-party SDK support), calling the gateway's REST API directly via Laravel's Http facade is often more reliable than trusting an unmaintained wrapper — worth weighing per-project rather than defaulting to a package.
Pick guide: full standalone app → Bagisto. Add e-commerce to an existing Laravel app → Aimeos or Lunar. Fully custom/composable → Vanilo.
Gig / Delivery Platform Building Blocks
Laravel's package ecosystem for real-time dispatch/geolocation is genuinely thin — most production gig/delivery platforms (including your own dispatchd-go work) end up hand-rolling geospatial indexing rather than relying on these. Listed for completeness:
If you're outgrowing haversine-in-PHP packages, this — plus raw queries — is the actual scalable path, same category of decision you already made going custom with sharded geohash in Go
See Kafka section below — relevant for event-driven order/dispatch pipelines at scale
Honest take: for anything beyond basic radius queries, Laravel packages won't get you where dispatchd-go already is (sharded geohash + Vyukov MPMC). These are useful for a Laravel-side admin/reporting layer talking to Postgres, not for replacing your matching engine.
Adds batch produce/consume on top of mateusjunges/laravel-kafka — useful if you're doing high-throughput event batches
Setup note: librdkafka (system lib) → pecl install rdkafka (PHP ext) → composer require mateusjunges/laravel-kafka, in that order. Most install failures come from skipping the system library step.
Gotcha: static properties, singletons, and closure-captured objects persist across requests — set max-requests/max-jobs recycle limits, register listeners only in service providers, never mutate static arrays in handlers.
Purpose-built for Redis queues — live dashboard of jobs (pending/processing/completed/failed), throughput graphs, wait-time metrics, per-queue breakdown, failed job retry UI, tags for filtering by job type
This is the right tool for queue monitoring at scale. Use this, not Telescope, for production job visibility.
Records individual job dispatches/executions as part of general request/event debugging — good for "did this one job run and what did it do"
Not built for live throughput/backlog monitoring — it's a debug log, not an operations dashboard. Fine for dev, wrong tool for watching queue depth in prod.
Exports Horizon's own metrics for long-term retention/alerting (Horizon's UI itself doesn't retain history well)
Add this once Horizon's built-in UI isn't enough for historical trend/alerting needs
For your setup: Horizon as the primary queue dashboard (real-time, per-queue), Pulse for overall app health at a glance, Prometheus+Grafana exporter once you need alerting/history beyond what Horizon's UI retains. Telescope stays for local dev debugging only — don't rely on it in production at this scale (it writes every entry to DB and will itself become a bottleneck under 500k req/sec).
University Multi-Module Platform Stack (Hostel/Transport/Halls + Full SIS)
Given the actual shape of the project — five Laravel projects: a combined booking system (hostel + transport + hall booking) and a separate full SIS (admissions → course catalog → marks → attendance) — here's what maps to each module.
Not a package — at this scale, race conditions on hostel room/hall slot booking need row-level locks, not application-level checks. This is the actual hard problem in a booking system, not a package gap.
Attendance at scale: Kafka (mateusjunges/laravel-kafka) or Redis Streams, not direct DB writes
If attendance is captured via biometric/RFID at thousands of scan events per minute across campus, direct synchronous DB writes will choke — queue the events, batch-write
filamentphp/filament for all admin panels — consistent look/UX across hostel/transport/hall/SIS admin screens with one shared design system
Inter-service communication
Kafka (mateusjunges/laravel-kafka) — SIS enrolls a student → event → hostel/transport systems react (auto-allocate room, activate transport pass) without tight coupling
Shared config/secrets across 5 deployments
Not a package — a shared .env management strategy (Vault, or even a private Composer package holding shared config helpers) matters more at 5-project scale than any single package
Fine for local dev, not what you run in production at 500k req/sec — don't confuse the two
Multi-stage Dockerfile with FrankenPHP base image
Production image should build once, run everywhere — Octane+FrankenPHP in the container, not PHP-FPM
Docker Compose for local multi-service dev (5 apps + Redis + Postgres + Kafka)
Practical for local dev across 5 interconnected Laravel projects; not what you'd run in prod at this scale — prod needs orchestration (see below)
Kubernetes / Nomad, or your own Porter (Firecracker microVM)
At 500k req/sec across 5 services, plain docker run on a few boxes isn't enough — you need real orchestration for autoscaling, rolling deploys, health-checked restarts. This is exactly the problem your own Porter project is aimed at — worth using your own tooling here rather than reaching for vanilla Coolify/Dokploy, which are built for much smaller scale.
PgBouncer
Mandatory in front of Postgres at this write volume — see Database Infra section above
Redis Sentinel or Redis Cluster
A single Redis instance backing Horizon queues + cache + sessions will itself become the bottleneck at this scale — needs HA/clustering
Bottom line on Docker + 500k req/sec + 5 Laravel projects: the container runtime (Docker) is the easy part. The hard part is orchestration and traffic shaping across 5 services with shared identity/auth and an event bus tying them together — that's an infra design problem your existing Porter/dispatchd-go work is already positioned to solve better than any Composer package list can.