What does your PHP stack actually look like in 2026?

I've been building PHP applications professionally for 10+ years, and I'm curious what everyone here is using these days.

Our current stack at work:

* PHP 8.3 + Laravel
* Vue.js on the frontend
* MySQL + Redis for caching
* Docker for local dev and deployments
* GitHub Actions for CI/CD
* AWS for hosting

We've tried moving parts to Node.js a couple of times, but honestly, we keep coming back to Laravel for anything business-critical. The ecosystem is just too mature and productive to give up.

A few things I've noticed in 2026:

* PHP 8.3 JIT is genuinely fast now; the performance gap with Node is much smaller than people think
* GraphQL adoption in PHP projects has grown a lot
* Redis has basically become a default part of every stack

Curious what others are doing, are you still on Laravel or have you moved to Symfony, Slim, or something else entirely? Anyone running PHP in a microservices setup with Docker and Kubernetes?

Drop your stack below 👇

[**https://mamotechnolabs.com/blogs/modern-php-tech-stack-2026**](https://mamotechnolabs.com/blogs/modern-php-tech-stack-2026)

https://redd.it/1senu9l
@r_php

PHP + Go ? An execution layer for web apps

A friend of mine has been working on an app called Doki (Github: imranscripts/doki) that turns prompts into runnable apps, and one design choice I found interesting was using Go for the execution layer.

Some parts of the system need to run a lot of tasks in parallel (for example Playwright tests across multiple apps/environments). Instead of keeping everything in the main stack (PHP), he introduced a small Go service to handle execution.

From what I’ve seen, it works well because:

* goroutines make it easy to run many workers concurrently
* low overhead when spawning parallel jobs
* straightforward worker pool patterns
* good fit for orchestrating external processes (Playwright, Docker, etc.)

The Go service which is in its own container basically acts as an execution engine:

* receives jobs (test runs, tasks, etc.)
* distributes them across workers
* manages process lifecycle and isolation

It seems like a clean way to separate orchestration from the main app while keeping performance predictable under load.

Curious if others here are using a similar pattern (mixing PHP with Go, or Node with something like Rust/Go) for parallel execution workloads.

https://redd.it/1seo01e
@r_php

🚀 I built a self-hosted visual workflow automation tool for Filament (Voodflow)
https://redd.it/1seqhfc
@r_php

More dependency considerations
https://stitcher.io/blog/more-depedency-considerations

https://redd.it/1seqojs
@r_php

More dependency considerations
https://stitcher.io/blog/more-depedency-considerations

https://redd.it/1ser8uy
@r_php

Laravel Nestedset: Effective tree structures for SQL databases

The new 7.3 version of the aimeos/laravel-nestedset package for managing trees using nested sets improves performance. It's an highly optimized version of the popular kalnoy/nestedset package which, unfortunately, has been virtually abandoned by its owner.

- Repo: https://github.com/aimeos/laravel-nestedset

The 7.3 release contains:
- Reduced number of queries
- Possibility to create own indexes
- Option to avoid model firing events on recusive deletion
- Optimized PHP code
- Improved indexes

To dig deeper into the package, please check:

- https://laravel-nestedset.org
- https://github.com/aimeos/laravel-nestedset

If you like the package, leave a star :-)

https://redd.it/1sermgu
@r_php

I built an Inertia.js bundle for Symfony

Hey,

I've been working on nytodev/inertia-bundle, a Symfony bundle that implements the Inertia.js server-side protocol, basically the Symfony equivalent of inertia-laravel.

What it does:

Full Inertia.js protocol (XHR visits, partial reloads, asset versioning, 302→303 redirects)
All prop types: optional(), always(), defer(), once(), merge(), deepMerge()
SSR support via HTTP gateway
Symfony 6.4 / 7.x / 8.0 compatible, PHP 8.1+

Note: This bundle targets Inertia.js v2. v3 support is in progress.

GitHub

Packagist



https://redd.it/1sevcz8
@r_php

🎊 SymfonyLive Paris 2026 : le wrap-up ! 🚀
https://symfony.com/blog/symfonylive-paris-2026-le-wrap-up?utm_medium=feed&utm_source=Symfony%20Blog%20Feed

https://redd.it/1sewmib
@r_php

Scythe: an SQL Compiler and Linter, making ORMs redundant

Hi Peeps,

I released Scythe — an SQL compiler that generates type-safe database access code from plain SQL. If you're familiar with sqlc, the concept is similar — sqlc was a direct inspiration. Since Scythe treats SQL as the source of truth, it also ships with robust SQL linting and formatting — 93 rules covering correctness, performance, style, and naming conventions, powered by a built-in sqruff integration.

## Why compile SQL?

ORMs add unnecessary bloat and complexity. SQL as the source of truth, from which you generate type-safe and precise code, gives you most of the benefits of ORMs without the cruft and hard-to-debug edge cases.

This is common practice in Go, where sqlc is widely used. I personally also use it in Rust — I used sqlc with the community-provided Rust plugin, which is solid. But sqlc has limitations: type inference for complex joins, nullability propagation, and multi-language support are areas where I wanted more.

## What Scythe does differently

Scythe has a modular, trait-based architecture built in Rust. It uses engine-specific manifests and Jinja templates to make backends highly extensible. Out of the box it supports all major backend languages:

- Rust (sqlx, tokio-postgres)
- Python (psycopg3, asyncpg, aiomysql, aiosqlite)
- TypeScript (postgres.js, pg, mysql2, better-sqlite3)
- Go (pgx, database/sql)
- Java (JDBC)
- Kotlin (JDBC)
- C# (Npgsql, MySqlConnector, Microsoft.Data.Sqlite)
- Elixir (Postgrex, MyXQL, Exqlite)
- Ruby (pg, mysql2, sqlite3)
- PHP (PDO)

It also supports multiple databases — PostgreSQL, MySQL, and SQLite — with more planned.

Most languages have several driver options per database. For example, in Rust you can target sqlx or tokio-postgres. In Python, you can choose between psycopg3 (sync), asyncpg (async PG), aiomysql (async MySQL), or aiosqlite (async SQLite). The engine-aware architecture means adding a new database for an existing driver is often just a manifest file.

Beyond codegen, Scythe includes 93 SQL lint rules (22 custom + 71 via sqruff integration), SQL formatting, and a migration tool for sqlc users.

- GitHub
- Documentation
- crates.io


https://redd.it/1seurw1
@r_php

Follow-up: Filament Compass

Hey everyone,

Earlier this week I posted about a repo I made called Filament Compass, which provides structured data to stop AI from hallucinating or using deprecated methods when generating code for Filament v5.

I wanted to drop a quick update: I've launched filament-compass-pkg, so you can now install this data directly into your projects via Composer!

Just to clarify how the two repositories work together:

The original repo remains the main source of truth. You can still use it to create your own custom "compass" or even refine the base data to better suit your needs.
The new pkg repo is the "result" repository that acts strictly as the provider for Composer/Packagist.

I sync the data manually between them using a script available in the main repo. If you want to run the script yourself or customize it, just drop the source repositories (filament, demo, filament-compass-pkg) into the source folder of the main repo, and update the sync.sh (and/or PLAN.md) file if you introduce any new folder structures or instruction update.

Installation & Documentation:

You can find the setup instructions in the README of the new package repo: https://github.com/aldesrahim/filament-compass-pkg

Note:
The new package is not tested thoroughly yet, but I've checked that Claude Code can successfully read the filament-compass skill and its documentation.

Let me know what you think, and happy coding!

https://redd.it/1sf21bu
@r_php

A different approach to PHP debugging
https://ddless.com/blog/technical-journey-building-php-debugger

https://redd.it/1sf4foa
@r_php

SymfonyLive Berlin 2026: Discover the Workshops!
https://symfony.com/blog/symfonylive-berlin-2026-discover-the-workshops?utm_medium=feed&utm_source=Symfony%20Blog%20Feed

https://redd.it/1sf3dc5
@r_php

PHP Tek Returns to Chicago May 19-21, 2026



Hi PHPers... come join us for 3 days of fun, networking, and learning. PHP Tek is the longest running PHP conference and is returning for our 18th annual show.

This year we will have our 3 normal tracks for PHP Tek, plus a 4th track dedicated to JavaScript presentations.

Use this link to get $100 off your ticket.


https://ti.to/phptek/phptek-2026/discount/reddit

https://redd.it/1sf5ptx
@r_php

👻 PHP Dead Code Detector is stable (after 4 years of development), newly supports even Laravel!
https://github.com/shipmonk-rnd/dead-code-detector

https://redd.it/1sfr3n7
@r_php

Feedback on my package Laravel Policy Engine

Hey gang,

I've been building a larger project but one of the most complex parts of it has been authorization. I really spent a lot of time thinking through the authorization model and wanted something like IAM policy documents but native to my Laravel app.

I am a long time Spatie fanboy and have used Roles & Permissions package for years, but for this particular build I'm working on, I don't think the data model was quite granular enough in the way I'm needing.

So over the last couple months I've been building Laravel Policy Engine which has been everything I've learned while working on my larger app. I've really tried to distill it down and harden it into a rock solid package.

The pitch is basically,

1. Declarative policy documents your entire authorization config lives in version-controlled JSON.
2. Scoped permissions roles are assigned per-scope (team::5, plan::pro), not just globally. One user can be an admin in one org and a viewer in another, without workarounds and such. Just declare it and it just works.
3. Permission boundaries, hard ceilings per scope, like AWS permission boundaries. Even if someone holds admin, the boundary has final say.
4. Deny rules rule everything, so !posts.delete overrides every allow, across every role. No "last role wins" ambiguity.
5. Wires into Laravel's Gate, so $user->can(), @can, authorize(), and can: middleware all just work.
6. Interface driven so every component is an interface. Swap the Eloquent stores for DynamoDB, swap the evaluator for a remote policy service, whatever. The API basically never changes.

Define your authorization as declarative JSON documents and import them the way you'd manage AWS IAM policies:

{
  "version": "1.0",
  "permissions": [
    "posts.read",
    "posts.create",
    "posts.update.own",
    "posts.delete.any"
  ],
  "roles": [
    {
      "id": "editor",
      "name": "Editor",
      "permissions": [
        "posts.read",
        "posts.create",
        "posts.update.own",
        "!posts.delete.any"
      ]
    }
  ],
  "boundaries": [
    {
      "scope": "plan::free",
      "max_permissions": ["posts.read", "comments.read"]
    },
    {
      "scope": "plan::pro",
      "max_permissions": ["posts.*", "comments.*", "analytics.*"]
    }
  ]
}

I've really tried to put this thing through the ringer so any feedback would be very welcomed. Worst case it will have a userbase of 1 (me haha) but if it's helpful to anyone else I wanted to share.


https://redd.it/1sg2zym
@r_php

C-level APCu key isolation based on FPM pool names (Zero-allocation)

Hey everyone,

APCu is arguably the best in-memory key-value store for single-node PHP applications. It’s blazingly fast because it runs within PHP's own master process. But it has one massive, well-known architectural flaw in multi-tenant environments: It lacks pool isolation.

If you run multiple independent applications on the same server, each in their own PHP-FPM pool (with their own system users), they still share the exact same APCu memory segment. Pool A can read, modify, or delete Pool B's keys.

The standard solution is relying on PHP developers to manually prefix their keys (e.g., $cache->set('app1_config')). Not only is this annoying to maintain, but it offers zero security if an application gets compromised—a malicious script can just iterate and modify out the neighbor's cache.

I decided to fix this at the C level.

I wrote a patch for the APCu extension that introduces a transparent memory hook. It automatically namespaces every cache key based on the active PHP-FPM pool, completely invisible to the PHP userland.

How it works under the hood (The C Magic):

Instead of allocating new heap memory (malloc/free) on every web request—which would destroy APCu's legendary speed—I engineered a zero-allocation memory reuse strategy:

Out-of-Band Pool ID: When an FPM worker spawns, the C code reads /proc/self/cmdline to safely extract the exact pool name (falling back to geteuid() if procfs is restricted).

Worker-Lifetime Persistence: On the worker's very first APCu call, it allocates a single, persistent zend_string buffer (default 256 bytes) that survives the request shutdown and is immune to PHP's garbage collector.

Raw memcpy & Zend Spoofing: On every subsequent cache request, the code uses a fast memcpy to drop the user's requested key directly into this persistent buffer right after the static pool prefix. It then mutates ZSTR_LEN and forcefully resets the hash (h = 0) to trick APCu into recalculating the hash for the new, secured string.

The Result:

A script in Pool A calls apcu_store('db_config', $data). Pool B calls the exact same thing. In physical RAM, they are securely locked away as pool_A_db_config and pool_B_db_config. No application intervention required. Zero performance penalty.

I've documented the exact architecture, installation instructions, and how to maintain the patch on future APCu releases.

GitHub Repo: https://github.com/Samer-Al-iraqi/apcu-fpm-pool-isolation

I'd love to hear feedback from other extension developers or anyone dealing with shared-hosting/multi-tenant PHP architectures!

https://redd.it/1sg9rln
@r_php

Flow PHP PostgreSql Symfony Bundle
/r/PHP/comments/1sfmlha/flow_php_postgresql_symfony_bundle/

https://redd.it/1sfmlwt
@r_php

I got tired of importing themes and tweaking CSS by hand, so I built a visual theme builder for my Laravel Starter Kit

[A complete theme builder for Saucebase laravel Starter kit.](https://reddit.com/link/1sgp4dn/video/ory7ede9z5ug1/player)

Hey everyone,

I've been using [tweakcn](https://tweakcn.com/) to generate themes for my projects, and it's a great tool , big inspiration for what I ended up building. But the workflow was always the same: generate a theme there, export it, import it into my project, then spend ages manually adjusting variables until everything actually looked right in context.

So I decided to build a visual theme builder directly into my project. If you're not familiar, I'm working on an open-source module-first Laravel SaaS boilerplate called Saucebase ([intro post here](https://www.reddit.com/r/laravel/comments/1ri1uc0/open_sourcing_a_modulefirst_laravel_saas/)). The theme builder is one of the modules.

Here's what it does:

* Live editor with color pickers, font selectors, shadow and radius sliders, you see changes instantly in your actual app, not a separate preview
* Dark/light mode support with per-field sync (link a value across modes or keep them independent)
* Shadow system where you tweak 6 base values and it computes 8 shadow scale strings automatically using `color-mix()`
* Same idea for border radius and letter-spacing with one base value, computed scale
* Google Fonts loaded on demand (Its use a static list for now, possibly I will integrate with the google fonts api)
* 15 built-in themes (named after food to keep the joke with the name, like beetroot, coffee, kiwi…)
* When you're happy, save a JSON, run `php artisan saucebase:theme:apply`, rebuild and done! Happy days

Important to note: **this is a developer tool, not an end-user feature.** You use it in your dev environment to design and bake your theme, then commit the result. In production, it's just plain CSS variables, no runtime overhead, no third-party dependency.

The most fun part to build was the dark/light mode editing experience. You can edit both modes from the same screen and toggle between them live. And for any color field, there's a little sync toggle, lock it and when you change that color in light mode, it automatically mirrors to dark mode (or vice versa). Sounds simple but getting the sync state right, deciding what should link by default and what shouldn't, and making it all feel smooth took way more iterations than I'd like to admit.

You can play with it on the demo: [https://demo.saucebase.dev/](https://demo.saucebase.dev/)

Documentation is still WIP, but the editor itself should be pretty self-explanatory. Would love to hear what you think, especially around the UX of the editor and whether the workflow makes sense. Open to feedback and suggestions.

https://redd.it/1sgp4dn
@r_php

How are people linking Stripe payments back to the original visitor session in PHP apps

I'm trying to answer a simple question for a small Laravel SaaS I run: which traffic sources actually produce paying users. Traffic itself is easy. GA4, Plausible, whatever, they all show pageviews, referrers, UTMs. The annoying part is when the user leaves your app for Stripe Checkout. Once payment completes, the signal you get back is a server side webhook. At that point you're holding a Stripe event, not the browser session that originally came from Twitter or HN or Google. So the problem becomes: how do you reliably connect those two worlds. Most straightforward approach I came up with was attaching a visitor id to the checkout session. Flow looks like this:

1. small JS snippet generates visitor_id
2. store source + UTM info in DB
3. attach visitor_id to Stripe metadata
4. when checkout.session.completed fires, map payment to visitor

That works, but it means you end up maintaining a mini attribution system (sessions table, source storage, webhook mapping). I use Plausible for traffic analytics because it's simple and privacy friendly, but it doesn't solve the visitor to Stripe revenue join either. While searching I found Faurya which basically productizes this exact idea: tracks the visitor session + source data and connects it to Stripe events so you can see which channels actually produce revenue. How are people here handling this in real projects? Are you storing visitor IDs in Stripe metadata, pushing conversion events back into GA4, doing attribution inside your own DB, or just not worrying about it at this stage?

https://redd.it/1sgqhdg
@r_php

SymfonyLive Berlin 2026: “Finding security vulnerabilities with static analysis.”
https://symfony.com/blog/symfonylive-berlin-2026-finding-security-vulnerabilities-with-static-analysis?utm_medium=feed&utm_source=Symfony%20Blog%20Feed

https://redd.it/1sgruvh
@r_php

SymfonyLive Berlin 2026: “How native lazy objects will change Doctrine and Symfony forever”
https://symfony.com/blog/symfonylive-berlin-2026-how-native-lazy-objects-will-change-doctrine-and-symfony-forever?utm_medium=feed&utm_source=Symfony%20Blog%20Feed

https://redd.it/1sgorh3
@r_php