Qbix Server

Yesterday, I posted on Reddit about a web server I launched that's written in pure userland PHP, managed its own preforked workers, and removed the need for NGINX and PHP-FPM.

It was already able to run 10x more concurrent workers (e.g. 1600 workers on an 8GB server).

The biggest bottleneck in PHP hosting is *memory*. Each php-fpm worker loads your entire framework independently: 30–60MB per worker. On an 8GB server, that's ~160 workers max. That's your ceiling for concurrent PHP requests.

Well, Qbix Server forks workers *after* preloading your classes. Thanks to copy-on-write from the operating system, all that shared code (framework, config, autoloader) uses memory only once. Each worker adds maybe 3-6MB for its per-request data.

This means you get to run 10x more workers, and each worker actually loads much *faster* because you don't have to bootstrap your entire framework, config, etc. on every request.

https://github.com/Qbix/webserver

But wait... it got faster.

Yesterday, some people were complaining that a userland-PHP server was "only" 70% as fast as NGINX for serving static files. Well, it's 24 hours later, and I'm back, baby! After caching more, it turns out that it's now 25-35% FASTER than NGINX even for static files (as long as you keepalive connections).

Don't believe me? Run the benchmarks. It comes with a test suite now.

But wait... it now supports sockets

Yes, it is wire-compatible with socket.io, and bundles it out of the box (no need for npm). Now you can just drop PHP files into folders, in order to:

1. Handle HTTP Requests. (Cleanup after request is handled.)

2. Handle Web Sockets. (Long-lived, cleanup after disconnect.)

3. Handle Rooms. (Long-lived, cleanup after last websocket leaves.)

In my opinion, the coolest thing is that this retains all the things that made PHP great:

1. Shared-nothing. No way to have memory or secrets leak between requests.

2. Normie-friendly. Just drop files into folders and things just work! No need for hot-reload even. Not even for websockets and rooms -- the old handler will work for the old connections, while the new one is loaded for the new ones.

3. Sequential processing, sure it means you occasionally miss out on fanning out concurrent I/O races, but it's much easier to understand the code.

Give it a try! It's MIT licensed. Enjoy 😄

Who this is for:

• PHP Developers who want to host things
• Normies who don't want to install and configure apache/nginx/varnish/go/ssl certificates/mysql/etc.
• People who just get the standalone binary and can host on their computer, without the internet even.

This was taken from the much larger all-in-one PHP platform:

https://github.com/Qbix/Platform

In an effort to increase transparency about the things we work on, we are happy to start sharing quarterly progress reports with the community. 🚀

Hi everyone,

Over the past few months, we've been building TadreebLMS, an open-source Learning Management System focused on enterprise and corporate training.

We've recently completed a major restructuring of the project

How can we use AI in our product and process to speedup the development, process and customer support ?

The project is built with:

• PHP / Laravel
• MySQL
• Bootstrap / JavaScript
• Docker

GitHub:
https://github.com/Tadreeb-LMS/tadreeblms

Issues:
https://github.com/Tadreeb-LMS/tadreeblms/issues

We have a huge roadmap like SCRUM Integration, UI upgrade as per FIGMA, Gap Analysis Module Integration, Integrations with HR Systems etc...

Please anyone experience or architect in PHP can give recommendation on best practices, gaps in the system etc..

Hey everyone,

I recently joined a new company as a developer, and I’m building our internal Attendance and Payroll system using Laravel and PostgreSQL.

Development is going well, but I’m relatively new to deploying Laravel apps in production. I need some guidance on choosing the right hosting and database setup based on my company's requirements:

App Scope & Needs:

• Core Features: Employee attendance tracking, HR management, and monthly payroll calculation/generation (PDFs, background processing).
• Database: Currently using PostgreSQL in local development and plan to stick with it.
• Company Requirement: Management wants full control over the system, server, and employee data (so no fully managed black-box cloud PaaS where we don't control the underlying infrastructure/server location).

Questions I have for the community:

1. Hosting: Given the need for complete control over the infrastructure, should I spin up a self-hosted VPS (e.g., DigitalOcean, Hetzner, AWS EC2) using Laravel Forge or Coolify, or setup a bare-metal LEMP stack manually?
2. Database Setup: Is running Postgres on the same VPS fine for a small-to-medium internal company tool, or should I decouple it onto its own dedicated instance/managed DB from day one?
3. Queue & Scheduler: Since payroll will generate PDFs and queue emails, what’s the best low-maintenance way to handle Laravel queue workers (Supervisor/Redis) and the scheduler in a production environment with complete server access?
4. Data Protection: What are the non-negotiables for securing sensitive financial and employee payroll data on a self-hosted server?

Would love to hear how you'd structure this setup! Any tips, common pitfalls, or architectural recommendations are greatly appreciated. Thanks!

[ Removed by Reddit on account of violating the content policy. ]

I wanted something like pyenv or nvm but for PHP. Couldn't find one that actually works the way those do — resolve deps, build from source, switch versions cleanly. The existing options either wrap pre-built binaries or half-ass the dependency resolution.

So I built phpv: https://github.com/supanadit/phpv

`phpv install 8.4` checks your system, builds whatever deps are missing from source, compiles PHP with the right flags. 25 default extensions, out of the box. Supports PHP 4.x through 8.x, version switching, per-project pinning via .php-version, PECL extensions, PHAR tools, portable bundles you can export and import across machines. Linux amd64/arm64 + macOS Intel/Apple Silicon.

Install:

curl -fsSL https://raw.githubusercontent.com/supanadit/phpv/main/install.sh | bash

Then:

eval "$(phpv init bash)"

phpv install 8

Honest con: it compiles from source, so first install is slow. There's no pre-built PHP binary cache yet — working on portable musl-static bundles so you can skip compiling entirely, but that's not done. What's there now works, it just takes a few minutes on first run.

It works. I've been using it on Ubuntu and macOS daily. But I know there are distros and edge cases I haven't hit — Alpine, Arch, weird setups. If you're on any of those, try it and file an issue if it breaks. I want to know.

Repo: https://github.com/supanadit/phpv

Issues: https://github.com/supanadit/phpv/issues

Break it and tell me.

I’ve been building Sumire, a small PDO mapper for PHP 8.2+.

The goal is to make mapping database rows to PHP objects concise without introducing the complexity of a full ORM, while preserving the transparency of PDO.

Sumire deliberately minimizes dependencies and implicit behavior so that database access remains understandable, debuggable, and maintainable.

Current features include:

- PHP attribute-based entity mapping
- SQLite, MySQL, and PostgreSQL support
- Persistence and repository APIs
- Criteria queries, pagination, count, and existence checks
- Transactions
- Basic table creation

Sumire is not intended to replace Doctrine or Eloquent. It is designed for applications that want to stay close to PDO while avoiding repetitive mapping code.

The project is still evolving, so I’d especially appreciate feedback on the API design and what you consider essential for a thin PDO mapping layer.

GitHub:
https://github.com/wind111-lang/sumire

Packagist:
https://packagist.org/packages/wind111-lang/sumire

I’ve been building it with the help of Codex.

recently I released xphp v0.3.0 -- and since a language is only as alive as its ecosystem, I also released:

1. language server
2. phpstorm and vscode plugins
3. collections: the first xphp library, using generics and variance-aware.

I wrote the whole story up here: https://math3usmartins.hashnode.dev/a-language-is-only-as-alive-as-its-ecosystem

I'm looking for criticism and skeptical feedback as much as I'm looking for contributors. xphp can't / shouldn't be maintained by a single person.

p.s. xphp is a superset of php. meaning it compiles into php like typescript compiles into javascript. the most relevant feature so far is generics with variance support. but it also supports closure signature types and other features are coming.

important: xphp is part of the php ecosystem by design. its goal is to help the ecosystem grow bigger and stronger. find more about that at https://github.com/xphp-lang/xphp/blob/main/README.md#ecosystem-and-community-first

A few weeks ago I posted a small framework here and got a lot of honest feedback. The clearest point, from several people, was that the file-based routing was the interesting part and would be more useful as a standalone library than baked into a whole framework. So I built that.

file-router is a zero-dependency package that maps your directory structure to routes, Next.js style: users/[id].php → /users/{id}, [...slug] for catch-all, route groups, compiled route cache. PHP 8.1+.

The part I think is actually useful: it's framework-agnostic. It runs standalone, but there are thin adapters so it plugs into Laravel (registers as native routes, inherits middleware/container) or Symfony (as a custom route loader, uses Symfony's own matcher and cache). So you can get file-based routing without adopting a new framework.

It's tested across PHP 8.1–8.5, and the migrations in the example template are verified on SQLite, MySQL and Postgres (not assumed; actually run end to end).

Repo: github.com/lizzyman04/file-router

Genuinely looking for feedback again, especially on the adapter approach. Does registering into the host framework's own router feel right to you, or would you expect it to work differently?

Every migration checklist makes it sound like ""set up your 301s and you're done,"" but almost everyone I've talked to has a horror story about rankings disappearing afterwards.

If you've migrated a large WordPress site, what ended up being the biggest risk? Was it redirects, internal linking, canonicals, crawl budget, or something you didn't even think about until after launch?

I'm looking into a few website migration services (one of them is IT Monks) because I'd rather avoid learning these lessons the hard way.

Looking back, would you still hire outside website migration services, or do you think a solid in-house team is enough if they plan everything carefully?

Cached pages seem fine but release pages like https://pecl.php.net/rest/r/amqp/stable.txt timeout

Anytime a WordPress site needs a Composer package (a PDF library, an API client, whatever),

you hit the same wall: no SSH access. Shared hosting, managed WP hosts that lock down the

filesystem, clients who only have FTP: Composer just isn't reachable from the terminal in a

lot of real-world WP environments.

The usual workarounds are either committing vendor/ directly to the repo (bloats it, breaks

on updates) or building locally and rsyncing the output (works, but no one tracks what's

actually installed on prod).

I built Loopress to fix this: a CLI plus a companion WP plugin. The plugin adds a Packagist

search inside the WP admin. You search a package, click install, and it resolves the

autoloader for you. Before installing, it checks PHP version compatibility and flags known

CVEs on the dependency. The CLI side also lets you lock exact plugin/package versions in a

loopress.json so environments stay reproducible.

It's still alpha. I'd be curious what parts of this feel over-engineered or missing to

anyone who's dealt with Composer-in-constrained-environments outside WP too. Is this a

WP-specific problem or does it show up elsewhere?

Docs: https://docs.loopress.dev

Code: https://github.com/loopress/loopress

What if PHP by itself was enough to run a web server?
What if it was actually *much faster* than NGINX + PHP-FPM?
And it was *much safer* than FrankenPHP or Swoole?

Well, that's exactly that this is. MIT-licensed. Enjoy!

https://github.com/Qbix/webserver

Who this is for:

• PHP Developers who want to host things
• Normies who don't want to install and configure apache/nginx/varnish/go/ssl certificates/mysql/etc.
• People who just get the standalone binary and can host on their computer, without the internet even.

Static file throughput is 55–73% of nginx (C will always beat PHP on raw I/O).

But on actual PHP workloads, the bootstrap savings make this 2–5x faster.

This was taken from the much larger all-in-one PHP platform:

https://github.com/Qbix/Platform

I've applied what we've been doing on mobile to building a fully native Mac app, and... it works!

(Content warning: Heavy British sarcasm used throughout, but don't let that distract you from the reality of the discussion.)

Prove it

I've posted a tweet about it for now with just a couple of screenshots. I'm not linking to it; you can easily find me on that hole of a website that just keeps sucking me in. In fact, I'm not going to link to anything as I'm sure I'll be accused of some kind of self-promotion.

More will come if folks are keen for this.

Why u do dis?

Web views just aren't great ways to build great apps. They're convenient, but they're crap.

I mean, sorry all you Electron/Tauri/Capacitor folks, they're fine if you want a mediocre app or to spend months of your life debugging performance issues.

But if you want a real native app that feels really at-home on the user's device, then your best option is to build real native apps.

Sadly there aren't really any good cross-platform solutions for that problem (don't come at me with Qt's and GTK's, those aren't "good" by any stretch of the imagination).

And certainly none for the PHP gang.

Also, I wanted to nail a few things in one go for what we've been doing on Desktop up until now:

1. Get rid of Electron - it's just so heavy and comes with a bunch of gotchas. Plus having node and npm packages in the build process is continuing to scare me. aint nobody got time for that.
2. Don't replace it with Tauri - yes it's lighter, yes it's Rust so the purists can be happy. Sadly it's just swapping one mediocre solution for another.
3. Drop the PHP built-in server - yep that's what we currently use. Yes it's a crutch (that has worked pretty well!), but the time has come for better stability and better performance, and we have everything we need now to make it work without it.

This manages all of that and a little more to boot. This PoC app I've built is just 24MB. Granted it's a PoC, so it's likely to grow from there, but it's a far cry from the minimum 130MB+ just for Electron.

So how does it work?

In case you haven't been following along what we've been doing on mobile - or perhaps you've been intentionally ignoring it because you have some bones to pick with either the name, the team, or the fact that it's using your favourite language in some profane way - we have cracked a very performant way to run PHP (>120fps ... like wayyyy greater than) and build reactive, native UIs without having it behave like a web server.

In fact, it behaves more like a game engine. It's very light on resource usage, has a ton of affordances already for native UI elements and allows you to write very idiomatic PHP code. All that without fundamentally changing PHP's core. Just adding our own extension.

We call it SuperNative. It kinda even looks a bit HTML-like, if you use Blade and squint hard enough. But deep down it's just PHP classes that compile to a custom binary format.

So there's no IPC, no HTTP calls, no multiple processes just to spin up an app. It's PHP compiled as an embed (exactly how we do it on mobile), embedded into the shell applications (in this case, a Swift macOS app), and called directly.

The application literally becomes a PHP interpreter. It boots PHP into an isolated thread that it keeps alive, feeding it messages and reading its output, all through shared memory.

Did I mention it's very fast? We're now measuring round-trips from button presses, through PHP and back out to the UI in microseconds (yup µs). And we can spin up multiple PHP threads as needed, in milliseconds (ms). And that's with a full Laravel application in there!

(Don't worry, it's still just PHP... if someone wants to help us make this not dependent on Laravel, or work with other frameworks, we'd be happy to have the support!)

All of this already works on mobile, and we're just starting to explore bringing it to the desktop.

What's the catch?

Our focus is on mobile as way more people seem to want that. But there are a few people still wanting advancement in the desktop space, so that's what we're trying to deliver.

This is only working on macOS for now, and it's just a proof of concept, but I'd love to tackle Mac, Windows and Linux all together.

To be able to do that, we gotta get some more sponsorship (you can sponsor nativephp on GitHub - you know how to use a browser and URLs, so I'll leave you to figure it out) and maybe then we can afford to take on yet another crazy huge project.

If this is at all interesting to you and you wanna help make it a reality, please reach out. I'm always open to chat irl and much prefer it to having anons sling zero-effect insults at me across Reddit.

I'm building an on-premise AI platform for software engineering and I'm looking for feedback—and hopefully to connect with people who might enjoy building it together.

The idea isn't to build another chatbot or compete with OpenAI. Instead, the goal is to combine deterministic static analysis with local LLMs and structured project knowledge.

Current stack:

• Symfony 8
• PHPStan
• PostgreSQL
• Python AI service
• Ollama
• Local RAG
• JSON-based analysis pipeline

The production application is currently private, but I've published the architecture and collaboration blueprint here:

https://github.com/chrobaks/php-local-ai-blueprint

I'm particularly interested in discussing:

• AI-assisted software engineering
• project knowledge representation
• local AI workflows
• agent orchestration
• static analysis
• RAG architectures

This is currently a passion project. I'm not a company and I'm not hiring. I'm simply looking for people who find this kind of technical challenge exciting.

If you're interested in exchanging ideas, discussing the architecture, or even contributing to the project, I'd genuinely love to hear from you. Whether you're a Symfony developer, Python engineer, AI enthusiast, DevOps engineer, technical writer, or someone interested in technical marketing and community building, you're very welcome.

Constructive criticism is just as valuable as code contributions.

Hi guys,
I maintain a private PHP framework (based on Laravel core) called Ariel, where I had been usingpecee/simple-router.

After upgrading the project to PHP 8.4+, I started encountering compatibility warnings. Since its latest stable release appears to date back to December 2023 and the project seems relatively inactive, I decided to replace it rather than maintain framework-specific patches.

I extracted the resulting router into a standalone open-source package:

Ariel Radix Router

The API is intentionally Laravel-like, while the implementation is a small standalone router with no runtime dependencies.

Main features:

• radix-tree route matching
• static, dynamic and constrained routes
• Laravel-like route declarations and groups
• cumulative route and group middleware
• predictable middleware execution order
• named routes and URL generation
• scalar-typed controller parameters
• compiled route catalogs and optional file cache
• explicit middleware lifecycles for persistent workers
• support for PHP-FPM, Workerman, RoadRunner, FrankenPHP and similar environments
• PHP 8.4+

The package uses PHPUnit, is analysed with PHPStan at the maximum level, and includes reproducible microbenchmarks. I’ve also integrated it back into the original framework and tested persistent request handling and memory stability under Workerman.

It is not intended to be a drop-in replacement for Pecee or Laravel’s router. The goal is to provide a focused, modern router with a familiar API and predictable performance.

I’d particularly appreciate feedback about:

• the public API
• middleware lifecycle design
• missing routing use cases
• benchmark methodology
• behaviour under long-running workers

I used Codex with GPT-5.6 Sol to help write automated tests, documentation and PHPDoc, run benchmarks, and identify bugs. All resulting changes were reviewed and validated with PHPUnit, PHPStan at the maximum level, integration tests and real Workerman runs.

GitHub: https://github.com/StefanoV1989/ariel-radix-router
Packagist: https://packagist.org/packages/stefanov1989/ariel-radix-router

Thank you in advance,
Stefano.

It's been a month since PHPverse 2026, which was a huge success. You can watch this year's talks here: https://www.youtube.com/playlist?list=PL0bgkxUS9EaK45-0M742u1WfK2G7FKXZQ

So we're already planning the next edition in 2027, and this time we're opening a public call for papers, everyone can submit: https://docs.google.com/forms/d/e/1FAIpQLSfp-_MYwaeVcDYZuPcL-YHHHikuoyB9hM7FUkpP2nUggba8hQ/viewform

plx is a PostgreSQL extension that lets you write stored functions and triggers in the dialect you already know (the current set is listed below). When you run CREATE FUNCTION, plx transpiles the body to plpgsql and stores that plpgsql in pg_proc.prosrc. At run time the function is executed by PostgreSQL's own plpgsql interpreter. There is no separate language runtime loaded into the backend, and nothing new to run in production.

$c = open_cursor("SELECT v FROM t ORDER BY v");
$row = fetch_from($c);
while (found()) {
  $total = $total + $row->v;
  $row = fetch_from($c);
}
close_cursor($c);

Pop quizz PHP for Friday evening :

how can you remove an argument from a method, between a parent and a child?

#phptip #phptrick

<?php

class x {
    function foo(int $a, string $c, string ...$b) {}
}

// OK
class y extends x {
    function foo(int $a, string ...$b) {}
}