To make this vision a reality, I have recently made dramatic improvements to the Symfony Docker project. While it remains the easiest way to spin up a Docker-based FrankenPHP skeleton for your Symfony applications, it now packs some incredible new capabilities out of the box.

Sandboxed Coding Agents

It is hard to imagine modern development without coding agents. Symfony Docker now ships with first-class integration for Claude Code.

If you have used agents locally, you likely know the friction of constantly approving execution permissions. We have solved this by allowing Claude Code (and other AI coding assistants) to run in a fully autonomous “YOLO” mode. This is achieved safely because the agent is natively sandboxed inside our environment. Security is strictly enforced via a provided default firewall script, which includes a strict allowlist restricted to essentials like Packagist and GitHub.

Read the detailed documentation about this new feature!

Native Dev Containers and Xdebug

Setting up local environments should never be a hurdle. Symfony Docker now supports Dev Containers, leveraging the open specification to define your entire environment. This brings out-of-the-box support for compatible IDEs and editors such as Visual Studio Code, PhpStorm, GitHub Codespaces, and Emacs, as implemented in PR #918.

Building on this foundation, we have seamlessly integrated Xdebug, the most popular step-by-step debugger for PHP. It is now pre-installed and configured to work immediately via the Dev Container setup. You just start the project, add a breakpoint in your editor, and it works flawlessly, even when FrankenPHP’s worker mode is enabled. You can read the technical details of this integration in PR #925.

Hot Reloading with FrankenPHP

On the server side, FrankenPHP has introduced a true game-changer for PHP development: hot reloading. If you have used modern JavaScript frameworks, you know how magical Hot Module Replacement feels. Now, you get that exact same experience in PHP.

FrankenPHP automatically watches your PHP, Twig, JavaScript, and CSS files for changes. When a modification occurs, it dispatches a Mercure update to the browser, reloads worker scripts, and refreshes the Symfony cache in the background. This eliminates the slow cache-repopulation step in development, bringing instantaneous updates directly to your browser. The full setup for this is available in PR #920.

Production-Ready, Rootless Images

Great DX during development is crucial, but deploying safely and efficiently is just as important. We have completely optimized the production images to be leaner and more secure than ever. The setup is now fully production-ready by default, featuring slim, rootless images. You can review the underlying architecture for this in PR #909.

SymfonyLive Paris 2026 Slides

If you missed my talk at SymfonyLive Paris 2026, you can find the complete slide deck embedded below. During the session, I demonstrated all these features, alongside a live demo showing how to remotely control a local Claude Code session straight from a mobile device.

Need Help Modernizing Your Stack?

Transitioning to these new paradigms can be challenging. At Les-Tilleuls.coop, we can help you automate your development workflows using coding agents, and we provide deep expertise for Docker, Symfony, and FrankenPHP. If your team needs assistance building or modernizing its infrastructure, feel free to reach out to us.

Finally, maintaining these tools and continuously pushing the boundaries of PHP takes a massive amount of time. If you or your company rely on Symfony, FrankenPHP, Symfony Docker, or API Platform please consider sponsoring me on GitHub. Your support directly fuels this free and open-source innovation.

Since the project’s initial release, this has been by far the most requested feature. While many of you have been successfully running FrankenPHP on Windows via WSL (Windows Subsystem for Linux), native support was the “white whale” we’ve been chasing for a long time.

Today, that chase is over. You can now run FrankenPHP natively on Windows, with 100% compatibility, including our killer features like Worker Mode and Hot Reloading.

Performance That Screams

We didn’t just want it to work; we wanted it to be fast. Early benchmarks from the community are already painting an incredible picture.

One user compared FrankenPHP against an already optimized Nginx/PHP-FPM environment on the same Windows Server 2022 machine. The results speak for themselves: a staggering 3.6x performance boost (an increase of over 260%) simply by switching the server runtime.

Additionally, new extensive benchmarks by @henderkes further validate these impressive gains natively on Windows across various workloads.

A quick tip for maximum speed: While native Windows support is incredibly fast and convenient for development and many production workloads, it is worth noting that for the absolute highest raw throughput, running FrankenPHP via WSL (Windows Subsystem for Linux) still yields more performant results due to Linux’s underlying I/O and networking architecture. In production, prefer using Linux if you can!

The Challenge: A Tale of Two Compilers

Why did it take so long to get here?

Some brave souls tried to port FrankenPHP to Windows early on (huge thanks to them!), but beyond the usual cross-platform headaches (file paths, filesystems), we hit a fundamental, structural wall.

Here is the technical issue in a nutshell:

1. FrankenPHP is a Go library that calls PHP’s libphp using CGO.
2. Official PHP builds on Windows are compiled with Visual Studio (MSVC) to ensure the best performance and stability.
3. Go’s CGO, however, had no support for Visual Studio on Windows. It historically only supported MinGW (GCC).

This left us with a massive compatibility gap. We couldn’t simply link the two together.

The Path to a Solution

We explored several options, each with its own dead end:

Option 1: Add GCC support to PHP for Windows. We considered patching PHP to support compiling with GCC. However, the PHP maintainers (understandably) weren’t keen on the extra complexity. We wanted to guarantee absolute stability, avoid ecosystem fragmentation, and use the official binaries directly, so relying on an alternative compiler than Visual Studio (MSVC), the only compiler officially supported by the PHP project, was a no-go.

Option 2: The “Frankenstein” Build (llvm-mingw). We tried an intermediate solution: compiling FrankenPHP with llvm-mingw and linking it against the official Visual Studio-compiled PHP. This failed because of the Standard Library mismatch. When you mix binaries compiled with MinGW (which uses msvcrt.dll or its own runtime) and MSVC (which uses ucrt / vcruntime), you run into critical issues. If one side allocates memory (malloc) and the other tries to free it, or if you try to pass file descriptors across the boundary, the application crashes. They effectively speak different dialects of “C”.

The Breakthrough: Go 1.26 and clang

We eventually realized the best path forward was to add support to CGO for the Clang/LLVM frontend provided by Visual Studio.

For those unfamiliar, Visual Studio includes a version of Clang that works as a drop-in replacement for the MSVC compiler (cl.exe). It accepts GCC-like flags (which CGO likes) but uses the Microsoft STL and runtime libraries under the hood. It’s the best of both worlds.

While exploring prior art and preparing to write a patch for Go, we stumbled upon an incredible, undocumented contribution from Google that did exactly this.

This patch made it into Go 1.26.

With this new capability in Go, and by using the lld-link linker, we were finally able to compile FrankenPHP using the same toolchain as PHP itself.

100% Green Tests

The result is a native Windows binary that links directly against the official, stable PHP binaries provided by the PHP project.

Crucially, because we link against the official PHP builds, all native PHP extensions supported on Windows work out of the box in FrankenPHP.

We updated the FrankenPHP codebase to handle the remaining Windows quirks, and I’m happy to report that all tests are green.

• Native Windows Binary
• Full Extension Support
• Worker Mode
• Hot Reloading

Credits & Sponsorship

This complex work was made possible thanks to the generous sponsorship of Intelligence X and Les-Tilleuls.coop.

Open Source sustainability is hard work. If your company relies on FrankenPHP, Caddy, or API Platform, please consider sponsoring me on GitHub. Your contributions allow me to dedicate time to solving deep technical challenges like this one and keeping the ecosystem healthy and fast.

Try It Now

This support has been merged in Pull Request #2119. You can download the latest binaries for Windows from our releases page!

A huge thank you to everyone who helped investigate this, specifically @TenHian for the initial exploration and @henderkes for the massive work on the final implementation.

Happy coding on Windows!

I’m thrilled to announce the immediate availability of FrankenPHP 1.11!

We have a special gift for the PHP community to unwrap this Christmas Eve. This release is laser-focused on improving the Developer Experience (DX) and deepening the integration between PHP and the Go ecosystem.

Here is what we put under the tree this year.

Built-in Hot Reload

This is the feature many of you have been putting on your wish lists. FrankenPHP 1.11 introduces a native hot reload capability designed to vastly improve your development workflow.

Forget mashing F5. This feature provides an experience similar to the Hot Module Replacement (HMR) found in modern JavaScript tooling. When you save a PHP file (or a template, or an asset…), FrankenPHP detects the change and updates the browser in real-time.

It leverages FrankenPHP’s built-in Mercure hub to push updates instantly. A support JavaScript library, built on top of the excellent Idiomorph library, will intelligently “morph” the DOM, preserving your scroll position and form input state.

This feature natively works with WordPress (showcased in the video), Laravel, Symfony, and virtually any PHP application.

How to use it

Enable the hot_reload option in your Caddyfile.

Warning: This feature incurs performance overhead as it watches the filesystem. Never enable it in production.

localhost

# Enable the built-in Mercure hub
mercure {
    anonymous
}

root public/
php_server {
    # Enable the hot reload feature
    hot_reload
}

For the best experience, if your app or framework supports the worker mode, combine it with the worker.watch directive. This ensures your worker script kernel restarts while the browser simultaneously updates:

localhost

mercure {
    anonymous
}

root public/
php_server {
    hot_reload

    worker {
        file /path/to/my_worker.php
        watch
    }
}

On the client side, just add the necessary JS libraries and meta element to your layout. The Mercure URL is automatically provided via $_SERVER['FRANKENPHP_HOT_RELOAD'].

<!DOCTYPE html>
<title>FrankenPHP Hot Reload</title>
<?php if (isset($_SERVER['FRANKENPHP_HOT_RELOAD'])): ?>
<meta name="frankenphp-hot-reload:url" content="<?=$_SERVER['FRANKENPHP_HOT_RELOAD']?>">
<script src="https://cdn.jsdelivr.net/npm/idiomorph"></script>
<script src="https://cdn.jsdelivr.net/npm/frankenphp-hot-reload/+esm" type="module"></script>
<?php endif ?>

Structured Logging with frankenphp_log()

Observability in modern applications is crucial. Go recently introduced standardized structured logging via the log/slog package, and we are bridging this capability into PHP.

The new frankenphp_log() function allows you to emit structured logs directly from your PHP code.

This is fantastic for production environments, as your PHP logs will now be formatted consistently with Caddy’s logs, making ingestion into platforms like Datadog, Grafana Loki, or Elastic, as well as OpenTelemetry support, much easier.

<?php

frankenphp_log(
    message: "User logged in",
    level: FRANKENPHP_LOG_LEVEL_INFO, // FRANKENPHP_LOG_LEVEL_DEBUG, FRANKENPHP_LOG_LEVEL_INFO, FRANKENPHP_LOG_LEVEL_WARN, or FRANKENPHP_LOG_LEVEL_ERROR, defaults to FRANKENPHP_LOG_LEVEL_INFO
    context: [
        "user_id" => 123,
        "ip" => $_SERVER['REMOTE_ADDR']
    ]
);

By default, as Caddy is configured to output structured JSON logs, this PHP call will produce a beautifully structured log entry in standard output:

{"level":"info","ts":1703690000.123,"logger":"frankenphp","msg":"User logged in","user_id":123,"ip":"192.168.1.1"}

Logging can be entirely customized using Caddy configuration.

Performance Improvements

FrankenPHP is already known for being fast but we want it to fly like a reindeer.

Thanks to rigorous benchmarking (with the help of Tideways), we identified and resolved bottlenecks under very high load. This results in better overall throughput in edge cases and, more importantly, improved tail latency (p95 and p99 benchmarks). Your application will be more consistent under heavy load.

We also significantly improved the performance of uncommon HTTP headers parsing by upgrading to version 2 of the Otter cache library.

Thanks to these patches, according to our benchmarks, FrankenPHP is now faster than PHP-FPM even without enabling the worker mode.

Unwrap “Le Monstre”

What is Christmas without toys?

We are delighted to announce that the official FrankenPHP plushy—affectionately known as “Le Monstre”—is finally ready for adoption!

For now, availability is exclusive to those who attended the API Platform Conference last September. If you were there, head over to Le Monstre shop and use your conference ticket number as the coupon code to unlock the checkout and claim your plushy.

For everyone else, don’t worry! Le Monstre will be available to the general public in early 2026.

Get it now!

I want to thank all the contributors who helped make this release possible. I hope you enjoy this release as much as we enjoyed building it.

Merry Christmas and Happy New Year from the FrankenPHP team!

Download FrankenPHP v1.11

This extension allows you to build high-performance gRPC servers using PHP, Go, or even a mix of both. It leverages the power of FrankenPHP’s Go extension support and the mature gRPC-Go library to deliver exceptional performance.

Ready to dive into the code? The brand-new gRPC extension is free and open-source and waiting for you on GitHub! If you’re as excited about bringing high-performance gRPC to PHP as I am, head over to the repository and give it a star . Your support is hugely appreciated and helps the project grow!

Key Features of the gRPC Extension

• High-Performance Server: Run a powerful gRPC server with FrankenPHP, executing your PHP code in a persistent worker loop for maximum efficiency.
• PHP and Go Handlers: Write your gRPC service handlers in either PHP or Go, giving you the flexibility to use the best language for the job. You can even mix and match them within the same server!
• Full gRPC-Go Compatibility: Benefit from all the features of the robust and widely-used gRPC-Go library.
• Pure Go Implementation: The extension is written entirely in Go, with no C code involved.
• East API Platform Integration: Seamlessly integrate with API Platform for building powerful and modern APIs.

This extension is highly experimental and not yet recommended for production use. It currently requires the main branch of FrankenPHP and its public API may change at any time without notice.

Getting Started

Let’s walk through how to set up a gRPC server with the new FrankenPHP extension.

1. Create a New Go Module for Your gRPC Server

go mod init example.com/mygrpcserver 

2. Create a Protobuf Definition

First, define your gRPC service and messages in a .proto file. Here’s a simple example:

syntax = "proto3";

option go_package = "example.com/mygrpcserver/helloworld";

package helloworld;

service Greeter {
    rpc SayHello (HelloRequest) returns (HelloReply) {}
}

message HelloRequest {
    string name = 1;
}

message HelloReply {
    string message = 1;
}

Then, generate the Go code from your .proto file:

protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative helloworld/helloworld.proto

3. Implement the gRPC Server in Go

Next, create the Go part of your gRPC server. This code will handle the gRPC requests and forward them to your PHP worker.

package mygrpcserver

import (
    "context"
    "fmt"

    pb "example.com/mygrpcserver/helloworld"
    "github.com/dunglas/frankenphp"
    phpGrpc "github.com/dunglas/frankenphp-grpc"
    "github.com/go-viper/mapstructure/v2"
    "google.golang.org/grpc"
    "google.golang.org/grpc/reflection"
)

func init() {
    phpGrpc.RegisterGrpcServerFactory(func() *grpc.Server {
        s := grpc.NewServer()
        pb.RegisterGreeterServer(s, &server{})
        reflection.Register(s)

        return s
    })
}

type server struct {
    pb.UnimplementedGreeterServer
}

// SayHello implements helloworld.GreeterServer
func (s *server) SayHello(_ context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {
    if in.Name == "" {
        return nil, fmt.Errorf("the Name field is required")
    }

    // Convert the request to a map[string]any
    var phpRequest map[string]any
    if err := mapstructure.Decode(in, &phpRequest); err != nil {
        return nil, err
    }

    // Call the PHP code, pass the map as a PHP associative array
    phpResponse := phpGrpc.HandleRequest(phpRequest)

    // Convert the PHP response (a map) back to a HelloReply struct
    var response pb.HelloReply
    if err := mapstructure.Decode(phpResponse.(frankenphp.AssociativeArray).Map, &response); err != nil {
        return nil, err
    }

    return &response, nil
}

4. Implement the gRPC Service Handler in PHP

Now, create a grpc-worker.php file to handle the logic of your gRPC service.

<?php

// Require the Composer autoloader here if needed (API Platform, Symfony, etc.)
//require __DIR__ . '/vendor/autoload.php';

// Handler outside the loop for better performance (doing less work)
$handler = static function (array $request): array {
    // Do something with the gRPC request

    return ['message' => "Hello, {$request['Name']}"];
};

$maxRequests = (int)($_SERVER['MAX_REQUESTS'] ?? 0);
for ($nbRequests = 0; !$maxRequests || $nbRequests < $maxRequests; ++$nbRequests) {
    $keepRunning = \frankenphp_handle_request($handler);

    // Call the garbage collector to reduce the chances of it being triggered in the middle of the handling of a request
    gc_collect_cycles();

    if (!$keepRunning) {
        break;
    }
}

5. Enable the FrankenPHP Extension with a Caddyfile

Create a Caddyfile to configure FrankenPHP and enable the gRPC extension.

{
    frankenphp
    grpc {
        address :50051
        worker grpc-worker.php
        min_threads 50
    }
}

6. Build and Run

Finally, build your custom FrankenPHP binary with the gRPC extension and run it.

Be sure to install FrankenPHP dependencies first.

XCADDY_DEBUG=1 \
    CGO_ENABLED=1 \
    XCADDY_GO_BUILD_FLAGS="-tags=nobadger,nomysql,nopgx" \
    CGO_CFLAGS="$(php-config --includes) -I/opt/homebrew/include/" \
    CGO_LDFLAGS="$(php-config --ldflags) $(php-config --libs) -L/opt/homebrew/lib/ -L/usr/lib" \
    xcaddy build

./caddy run

Your gRPC server will now be running on localhost:50051. I recommend using a tool like gRPC UI to test your new server.

I’m excited to see what the community builds with this new capability. Your feedback is highly welcome, so please give it a try and share your thoughts!

Here are the slides I presented during the keynote:

After months of meticulous stitching, we’re thrilled to announce the official release of the FrankenPHP elePHPant plushie! This isn’t your average plushie—it’s a grotesque yet charming creature, a patchwork of code and fluff, and the perfect companion for those late-night coding sessions.

Dare to adopt this creature of the night? Here’s how to get your very own FrankenPHP elePHPant:

API Platform Conference Attendees

The first batch of FrankenPHP elePHPants will be unleashed at the API Platform Conference in Lille. Come find us at our booth to claim one before they return to the shadows forever!

Online Attendees

For those attending the conference virtually, a limited number will be available to purchase online immediately following the in-person event. Check your conference attendee emails for the link to our crypt.

General Availability

If any of our monstrous creations remain after the conference, they will haunt our online shop a few weeks later. Stay tuned for updates.

10,000 on GitHub

This important milestone was reached just a few months after the project joined the PHP Foundation, thanks to the hard work of the maintainers and contributors, those who spread the word about the project, and everyone who tested it and reported bugs. A big thank you to all of you!

As promised, to celebrate, we have launched the production of stuffed ele(Franken)PHPants. The first specimen will be available exclusively at the API Platform conference, which will take place in September in my city of Lille.

A big party for the 10K stars and the 10th anniversary of API Platform will also take place there.

Places are filling up fast, but there are still a few available. Hurry up and grab yours if you want to be part of it and get your little monster plush toy

Let’s review some of them.

Thread Autoscaling

Until now, it was necessary to statically define the number of threads that FrankenPHP uses to handle PHP requests. By default, FrankenPHP starts two times more threads than the number of CPUs on the machine: this is often not optimal. The proper number of threads to start depends heavily on your application itself and your hardware. We provide extensive documentation explaining how to find the best suitable value.

Starting with version 1.5, Alexander Stecher added a new way: thread autoscaling. When using this mode, FrankenPHP will automatically spawn additional threads at runtime up to a specified limit. This new max_threads directive can help you figure out how many threads you need to handle your traffic and can make the server more resilient to latency spikes. If set to auto, the limit will be estimated based on the memory_limit set in your php.ini. This new mode is similar to PHP FPM’s pm.max_children.

Read the related documentation

Maximum Wait Time

Alexander also added a new option to limit the time a request can be buffered, waiting for a PHP thread to be available. This helps the server to recover faster during latency spikes by not allowing an endless accumulation of queued requests.

When the new max_wait_time is set, if the timeout is reached, a 504 “Gateway Timeout” error will be returned.

Mostly Static, glibc-based Static Binaries

One of the key features of FrankenPHP is that it can be downloaded as a fully static binary that contains FrankenPHP itself, a web server (Caddy), the PHP engine, the most popular PHP extensions, and their dependencies.

This means that you can execute FrankenPHP by downloading a single executable file containing everything without having any system dependencies.

This fully static binary is using the musl-libc and PHP has some known issues when using musl (especially with OpenSSL). Also, musl is known to be slower than the GNU libc in some circumstances.

static-php-cli, the tool that FrankenPHP uses under the hood to create its static builds, recently gained the ability to build “mostly static” versions of libphp. This means that all required system libraries are statically linked (so they don’t have to be installed on the system), except the libc itself. Thanks to this trick, FrankenPHP will link against the local installation of the GNU libc, which is available by default in most popular GNU/Linux distributions.

Since FrankenPHP 1.5, thanks to Jerry Ma and Marc “henderkes” (who are also the authors of this feature in static-php-cli), we provide mostly static builds of FrankenPHP that can be downloaded directly from the GitHub releases (the frankenphp-linux-<arch>-gnu files).

In addition to better stability and performance, Mostly Static builds also have the benefit of being able to load dynamically built PHP extensions, including Xdebug and FFI, which are not supported by musl-based builds!

Debian/Ubuntu and RedHat Packages

Mostly Static binaries also unlocked another feature that has also been contributed by Marc “henderkes”: official RPM and deb packages!

In addition to the Homebrew packages, starting from FrankenPHP 1.6, packages for Debian/Ubuntu and RedHat are built in the CI and provided in the GitHub releases!

In the future, package repositories will be set up (help welcome!).

Site-Specific Workers

Marc (he’s on fire!) also added the ability to define workers for a specific site instead of globally for all sites. This enables us to write a Caddyfile like this:

{
    frankenphp
}

one.example.com {
    php_server {
        root /var/www/app-one
        env APP_NAME one
        worker index.php 16 # 16 instances of the worker script will run in parallel
    }
}
two.example.com {
    root /var/www/app-two
    php_server {
        env APP_NAME two
        worker {
            file index.php
            num 8 # 8 instances of the worker script will run in parallel
        }
    }
}

Caddy 2.10

FrankenPHP 1.6 is now built on top of Caddy 2.10. This brand new version of our favorite web server comes with a bunch of new features, including Encrypted Client Hello, post-quantum (PQC) key exchange or global DNS providers.

Support The Project

This week, Les-Tilleuls.coop, the PHP Foundation and the Caddy team announced that FrankenPHP is now officially supported by the PHP Foundation.

Also, many talks about FrankenPHP have been announced at the API Platform Conference, in September in France. Be sure to be there, to meet some of the main contributors of the project will too!

To support the project, please contribute, give it stars on GitHub, and sponsor me!

PHP is a programming language used by around 70% of websites and applications, and by key software and frameworks such as WordPress, Laravel,and Symfony.

FrankenPHP offers a host of new features that allow to:

• simplify the development of applications written in PHP;
• drastically improve performance, while considerably reducing hosting costs (FinOps) and energy consumption (GreenOps);
• facilitate deployment in production, whether on bare-metal servers or in cloud-native environments;
• easily develop real-time features thanks to native Mercure protocol support;
• extend PHP apps with Go, C, and C++ programming languages;
• support the PHP programming language in any application written in Go (server, proxy, in-house development…).

Specifically, FrankenPHP integrates the official PHP interpreter as a module for Go and Caddy, the popular next-generation web server that supports the latest web platform innovations in terms of performance, security, and DevOps: HTTP/3, compression with Zstandard, 103 Early Hints, automatic generation and renewal of HTTPS certificates, Encrypted Client Hello, structured logs, OpenMetrics/Prometheus metrics… Caddy is also co-maintained by Kévin and sponsored by Les-Tilleuls.coop.

Thanks to its innovative architecture, FrankenPHP lets you install a complete PHP environment (interpreter, web server, extensions, etc.) optimized for performance and security, by downloading a standalone statically compiled executable or a Docker image.

FrankenPHP also offers a performance-optimized mode called “worker mode”, which takes advantage of the capabilities of the Go programming language. When this optional mode is used, the PHP application will be able to retain in memory those elements that can be reused to process other HTTP requests instead of being completely reset to process each incoming HTTP request (“share nothing” model). Worker mode is especially useful for frameworks such as Symfony and Laravel that can prevent rebuilding their kernels and services again and again for nothing.

Using this mode requires minimal adaptations to the code of modern PHP applications in line with good programming practice. The Laravel, Symfony and Yii frameworks already offer official integrations of FrankenPHP’s worker mode, enabling worker mode to be activated without modifying the application code.

According to an analysis carried out this summer by Sylius, the publisher of the eponymous e-commerce platform, the use of FrankenPHP’s worker mode reduces the software’s response times by 80%, while reducing by more than 6 the number of machines required to serve the same number of users.

FrankenPHP is now a reliable, mature solution used in production for an ever-increasing number of projects. The project now has almost 8,000 stars on GitHub, has passed the symbolic 100-contributor mark, and is officially supported by numerous hosting providers, including Upsun, Laravel Cloud, and Clever Cloud.

To get to this point, it was necessary to initiate close collaboration between the development teams of FrankenPHP, the PHP interpreter itself, the Caddy web server, and even the Go programming language.

Today, we’re proud to announce that, with the aim of intensifying this collaboration, enabling the project to gain momentum, and modernizing the entire PHP ecosystem, the FrankenPHP project is now officially supported by the PHP Foundation.

In concrete terms, FrankenPHP’s source code will be transferred to the PHP project’s GitHub organization, and the PHP Foundation team will contribute to the maintenance and development of FrankenPHP to ensure its reliability, durability, and compatibility with the latest language innovations.

Part of the FrankenPHP documentation will also be transferred to the PHP website.

The governance of the project remains unchanged, and the current team of maintainers (Kévin Dunglas, Robert Landers, Alexander Stecher) will continue to be in charge of releases, as well as code reviews. They will be actively collaborating with the PHP Foundation team in charge of the language development.

In addition to the support provided by the foundation, Les-Tilleuls.coop will continue to sponsor FrankenPHP (as well as PHP and Caddy) by providing developers and contributing financially.

FrankenPHP is already promoted by Caddy as the official, modern solution for using PHP with this server.

In the future, to simplify the PHP development experience (one-line installation of a complete development environment) and to promote a solution that, for projects requiring it, considerably improves the performance and efficiency of PHP applications, FrankenPHP may be highlighted on the PHP website as one of the ways to use the language (other SAPIs such as PHP-FPM will continue to be fully supported solutions).

To find out more about FrankenPHP and the many new possibilities it offers, take a look at its documentation. To meet the software’s authors and find out how it is used in production, don’t miss the API Platform conference (by the same authors as FrankenPHP) taking place on September 18 and 19 in France (Lille). 

Also, join us online for PHPverse on June 17 — a special event celebrating PHP’s 30th anniversary.

Finally, to help keep the PHP ecosystem innovating, support the foundation!

Les-Tilleuls.coop
The PHP Foundation
The Caddy team

One of Symfony’s strengths is its caching mechanism (the files stored in “var/cache”), which enables framework components such as the dependency injection container and the router, as well as numerous bundles, to be ultra-fast in production.

However, during development, regeneration of this cache can cause slowness and make the work of programmers tedious. Each time a PHP file, configuration file or Twig template is modified, all or part of the cache must be regenerated.

The latest version of FrankenPHP contains a new feature which, coupled with worker mode, can change all that: watchers.

After presenting how Symfony’s caching mechanism works, and how to take advantage of it in our applications and bundles, we’ll discover how to use watchers and FrankenPHP’s worker mode to ensure that changes made to our code are reflected almost instantaneously in our browser, and thus avoid the frustration of long loading times in dev.

I gave this presentation at SymfonyLive Paris 2025.

Compressing HTTP responses can significantly improve the performance of your PHP and Symfony applications. But you must still navigate the jungle of standards and formats.

In this presentation, we’ll discover how HTTP compression works, the different formats supported by modern web browsers (deflate, gzip, Brotli, and the brand-new Zstandard), and how to use them correctly.

We’ll also look at which formats to compress, which not to, when to use dynamic compression, and when (and how) to pre-compress responses that can be compressed for even better performance.

After that, I’ll introduce a new feature I just added to the Symfony AssetMapper component: pre-compression.