- How do I install orchid/socket in a Laravel application?
- Install it with Composer, publish its config file, set the broadcast driver, then point Laravel Echo or pusher-js at the daemon host and port. The server runs as a long-lived process via php artisan socket:serve, so you must supervise it with systemd or Supervisor. Initial wiring is typically about a day of work, and host, port, connection limits, queue integration, and auth guard settings are all config-level.
- Which Laravel and PHP versions does orchid/socket support?
- The package has no meaningful documentation or visible release cadence, so supported Laravel and PHP versions are not published. Read composer.json and the git log directly to confirm constraints, and check for commit activity in the last twelve months. It depends on pcntl/posix and a long-running event loop, and compatibility with Laravel 11 or 12 should be treated as unverified until you test it yourself.
- How does orchid/socket compare to Laravel Reverb?
- Laravel Reverb is the first-party answer to the same problem and ships with framework compatibility guarantees, while orchid/socket is a zero-adoption third-party package built on Ratchet. Both use the same architectural shape: a separate long-running daemon beside the HTTP runtime. Choosing orchid/socket over Reverb requires a documented, defensible reason, because we did not know Reverb existed will not survive architecture review.
- Can orchid/socket scale horizontally across multiple nodes?
- No, not without extra work. Channel membership and presence state live in the daemon's memory, which is fine on a single node but breaks under horizontal scaling unless you add a shared pub/sub backplane. Treat multi-node and high-availability requirements as out of scope, and avoid it for autoscaled containers, ephemeral instances, serverless, or high-frequency collaborative workloads.
- How does private and presence channel authorization work in orchid/socket?
- Private-channel authorization performs a handshake back into your Laravel application for each connection, which adds per-connection latency you must budget for. The auth guard wiring is configuration-level, and presence channel membership is tracked in the daemon's memory. Plan for the extra round trip when sizing connection volume and response times.
- Does orchid/socket work with laravel-echo and pusher-js?
- The package is designed to plug into Laravel's broadcasting abstraction, so broadcast helpers and ShouldBroadcast events stay as the only seams your application code touches. The critical question is whether it implements the Pusher protocol faithfully enough for stock laravel-echo and pusher-js clients, or whether it needs a bespoke client. Verify that in the source before committing, because a custom client changes the integration cost significantly.
- How do I run orchid/socket in production with TLS and WSS?
- Terminate TLS at nginx or an ALB and proxy WebSocket traffic to the daemon, then configure origin and CORS allowlists and tune proxy idle timeouts so long-lived connections are not cut. Use a process supervisor to keep php artisan socket:serve running, and implement graceful restarts so clients reconnect instead of silently dying. This operational work, not functional testing, is where production feasibility is decided.
- Is orchid/socket actively maintained and safe for production?
- It has zero stars, zero dependents, a maturity score around 0.3, and no visible release cadence or security contact, so it is effectively a personal project rather than a maintained ecosystem component. Adoption means ownership, not procurement: you inherit patching and compatibility work. An unmaintained package holding write access to your real-time layer is an unpatchable surface if the maintainer walks away.
- Can orchid/socket push real-time updates to Orchid admin screens?
- Yes, that is one of its stated use cases: pushing notifications, admin alerts, and live job or deploy status into Orchid admin screens without relying on external services. It fits a small-to-mid Laravel monolith on one or two long-lived nodes with low thousands of concurrent connections. It is a poor fit for high-frequency collaborative workloads or horizontally scaled deployments.
- What operational risks should I expect from the orchid/socket daemon?
- Watch for event-loop blocking on slow handlers, unbounded memory growth over long uptimes, pcntl/posix and PHP version constraints, and dependency drift against Laravel major releases. Without graceful restart and reconnect handling, clients can die silently. These risks are operational rather than functional, so only running the daemon under realistic production conditions will close the gap.