r/PHP • u/luzrain • 11h ago

I released PHPStreamServer 0.9: dynamic workers, native OS integration, and a redesigned message bus

Last year I shared PHPStreamServer here.

PHPStreamServer is an event-loop-based application server and process manager built entirely in PHP. It brings HTTP serving, worker supervision, scheduled tasks, logging, and metrics into a unified runtime.

Applications remain loaded between requests, with asynchronous execution powered by Revolt event loop and AMPHP.

I've been quiet publicly since my last post. During that time, I've continued using it as the primary runtime for my personal projects and improving it based on the experience. I've now released version 0.9, the project's biggest update yet.

One of the biggest architectural changes in 0.9 is that PHPStreamServer now requires FFI. This allows it to call native OS APIs directly for capabilities such as Unix-socket peer credential verification, parent-death signaling, and native file monitoring.

Some highlights:

  • Workers and scheduled tasks can now be registered and removed dynamically at runtime.
  • Message-bus commands are now a public API, allowing workers to send requests directly to the master process, for example, to start or stop on-demand workers dynamically.
  • The Unix-socket message bus was redesigned with security as a major focus. It now validates peer credentials and enforces source authorization, preventing unprivileged local users from managing a server running under a privileged account. Deserialization is also restricted to reject unsafe payloads.
  • File monitoring now uses native inotify on Linux and FSEvents on macOS, with polling as a fallback.
  • On Linux and FreeBSD, workers now use OS-level parent-death signaling, so they terminate instead of continuing as orphaned processes if the master process crashes or is killed.
  • Daemon startup now waits for the master process to initialize before reporting success.
  • Worker startup, shutdown, crash reporting, and log delivery are now more reliable.
  • The supervisor now reports non-zero worker exits and termination by operating-system signals.
  • The scheduler now supports named weekdays and months, presets such as @daily, and uses fractional-second delays for more accurate execution.
  • The public API now uses consistent worker terminology across all components.
  • Console and log output were redesigned to give PHPStreamServer a distinct and consistent visual identity.
  • Per-process network traffic monitoring now batches and sends only traffic deltas through the message bus, reducing inter-process communication overhead.

I also refreshed the documentation website with a redesigned landing page. You can check it out here:

Documentation:
https://phpstreamserver.dev/

GitHub:
https://github.com/phpstreamserver/phpstreamserver

Version 0.9 release notes:
https://github.com/phpstreamserver/phpstreamserver/releases/tag/v0.9.0

PHPStreamServer is still experimental and not yet recommended for production use.

I'd especially like feedback from developers working with long-running PHP applications, async PHP, FrankenPHP, RoadRunner, or OpenSwoole. What would you need to see before considering an application server like this for one of your projects?

7 Upvotes

82% Upvoted

4 comments sorted by

1

u/gadelat 9h ago

Seeing scheduler, I was expecting it to contain support messagebus/queue as well. Do I just not see it, or it's not there?

1

u/luzrain 9h ago

Can you clarify what you mean by messagebus/queue support in the scheduler? The scheduler is only responsible for scheduling tasks and running them periodically, similar to cron.

1

u/gadelat 8h ago

Dispatch message to be processed immediately (or optionally with delay), but async. Ideally with support to plug in different brokers like rabbitmq. Ideally for doing stuff like sending emails, notifications, that sort of stuff. So what symfony/messenger is doing, except symfony/messenger isn't taking advantage of event loops so it's slow.

1

u/luzrain 8h ago

You can use rabbitmq with it as usual, there is no difference when using this application server. There is no separate plugin for this because you can use existing solutions directly. For rabbitmq, there is an event-loop-compatible driver: https://github.com/thesis-php/amqp, but you can use any driver as well, such as the ext-amqp extension, if you don't really need full asynchrony.

PS. Don't mix up asynchrony (same-process concurrency) with dispatching a message through a message bus to be processed by an external worker.