Roadrunner Tcp Laravel Package

Product Decisions This Supports

• Enables building high-performance internal services with custom binary protocols (e.g., IoT device communication, game server logic, or real-time data pipelines) where HTTP overhead is prohibitive.
• Supports roadmap initiatives requiring ultra-low-latency, persistent connections by leveraging RoadRunner’s worker model to eliminate repeated PHP bootstrapping costs.
• Justifies "buy over build" for TCP-based communication layers—avoiding custom server implementation while integrating seamlessly with existing RoadRunner infrastructure.
• Now a stronger strategic fit for platform standardization: with 4.3.x aligned to RoadRunner v3 and consolidated under the official roadrunner/tcp name, TCP transport can be treated as a first-class, vendor-maintained component of the RoadRunner stack rather than a bolt-on.
• 4.3.1 removes the last piece of legacy naming friction (the package now requires roadrunner/roadrunner rather than spiral/roadrunner), so dependency manifests and security tooling reflect a single, consistent vendor namespace—reducing audit noise and "which package do we track?" ambiguity in the dependency-review process.
• Prioritizes infrastructure cost reduction by optimizing resource usage for internal RPC or microservice communication versus HTTP-based alternatives.

When to Consider This Package

• Adopt when:
  • Internal services require raw TCP communication (e.g., non-HTTP protocols like custom binary formats or UDP-like reliability layers).
  • The project already uses RoadRunner for other components (e.g., HTTP workers or queue processing), ensuring consistent tooling and process management.
  • The platform is on (or migrating to) RoadRunner v3—the 4.3.x line tracks v3, so runtime and package versions should be upgraded together.
  • Pin to 4.3.1 or later, not 4.3.0. 4.3.0 still declared a dependency on the legacy spiral/roadrunner package, which can pull in a v2-era runtime alongside the v3 stack or fail to resolve in a v3-only project. 4.3.1 corrects this to roadrunner/roadrunner.
  • Performance-critical use cases where minimizing request/response latency is non-negotiable (e.g., high-throughput financial data streaming).
• Look elsewhere when:
  • Standard HTTP(S) is sufficient for public-facing APIs or client-facing services (use the RoadRunner HTTP transport package instead).
  • TLS encryption is required out-of-the-box (this package lacks native TLS support; additional proxy layers would be needed).
  • The team is pinned to RoadRunner v2 and cannot schedule an upgrade—stay on the 4.2.x line, which will not receive v3 alignment.
  • The team lacks RoadRunner experience or the project is small-scale where HTTP simplicity outweighs TCP performance gains.
  • Broader community support or enterprise-grade features are critical (given the package’s low GitHub stars and niche use case).

How to Pitch It (Stakeholders)

Executives: "This package lets us build internal systems 10x faster with 50% lower resource usage than HTTP-based solutions—cutting infrastructure costs while enabling real-time capabilities for critical workflows like IoT or financial processing. The 4.3.x line brings it fully in line with RoadRunner v3 and the official roadrunner/tcp naming, and the 4.3.1 patch closed the last gap by moving its dependency onto the vendor-maintained roadrunner/roadrunner package. That lowers our long-term maintenance and supply-chain risk and keeps us on a supported, vendor-aligned path. It leverages our existing RoadRunner investment, so we avoid reinventing the wheel and ship high-performance features faster."

Engineering: "It’s a plug-and-play TCP transport for RoadRunner that handles raw socket management so you don’t have to. No more writing custom server logic—just define your binary protocol, integrate with workers, and get production-ready performance with built-in process scaling. Perfect for internal RPC, game servers, or anything where HTTP headers add unnecessary overhead. Heads-up on the 4.3.x line: the package was renamed to roadrunner/tcp and now targets RoadRunner v3, so treat the upgrade as a coordinated change—update the dependency name, confirm the v3 runtime, and regression-test worker bootstrapping. Use 4.3.1, not 4.3.0: 4.3.0 declared spiral/roadrunner as its dependency, which can drag in the legacy v2 package tree or break Composer resolution on a v3-only project; 4.3.1 changes this to roadrunner/roadrunner. After upgrading, run composer why spiral/roadrunner and, if it still appears, remove it from require/replace and re-resolve. Projects still on RoadRunner v2 should stay on 4.2.x until the platform upgrade lands."