As Roman Pronskiy's term on The PHP Foundation Board comes to an end, he is replaced by the wonderful Brent Roose, from a unanimous vote. Welcome Brent! 🚀 And thank you for your years of dedication and commitment to The PHP Foundation, Roman! ❤️🐘

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?

Sometime ago I was working in a Delivery Management System, we heavily incorporated the Service Repository Pattern to support all the features and capabilities of the system that was launched after 9 months of development and testing (a team of 2 developers, 1 QA tester and a project manager).

I recently started writing an article about this pattern and my opinions about it and I started to think, how would a bigger team preferablly with a software architect would go about reading the scope and coming up with a blueprint, how much architecture is worth building upfront vs overtime?

Article I have been working on: https://blaze64.dev/logs/laravel-service-repository

Join us for The PHP Foundation Community Hour, an interactive podcast that helps you understand how you can contribute to the PHP ecosystem! Shout-out to PHP Architect for providing the infrastructure, platform, and technical support to enable us to host these episodes. 🧡

bun-php allows you to run PHP functions seamlessly in Bun by exposing them as ESM imports. Uses a WASM build of PHP under the hood, no need to install PHP or native deps. Supports Composer and servers. https://www.npmjs.com/package/bun-php

Hi everyone,

I’ve just released the first public version of PHPFlow, an open-source static flow analyzer for PHP/Symfony applications.

The idea came from a problem I regularly run into on larger applications: answering a question like “what actually happens when this route is called?” can mean jumping through a controller, several services, Messenger dispatches and handlers, repositories, database queries and external APIs.

PHPFlow analyzes the source code without running the target application and reconstructs those flows as a graph.

For example, it can help answer:

• What happens when this Symfony route is called?
• Which routes/messages can reach this database table?
• What depends on this service?
• Where is this Messenger message handled?
• Which flows call this external API?
• Where can this exception surface?

v0.1.0 currently understands Symfony routes, dependency injection, Messenger, repositories, Doctrine DBAL/QueryBuilder, external HTTP calls, exceptions and a number of control-flow patterns.

It also generates a self-contained interactive HTML viewer with search, functional lanes, Messenger boundaries, minimap, path-to-effects and critical-path exploration.

PHPFlow is deliberately conservative: if it cannot prove a relationship statically, it doesn’t invent one. It also never boots or executes the application being analyzed.

There’s a bundled Symfony demo, so after cloning:

make setup make demo 

I’m especially interested in trying it against real-world Symfony applications now. If you give it a try and it misses a pattern used by your project, I’d really like to hear about it.

GitHub: github.com/patryyyck/phpflow

Feedback, bug reports and criticism are very welcome.