Add Caddyfile configuration

It appears this might conflict with the new standard from the Core team and Drupal Security Team attempting to slim down on the amount of security surface area by removing supported servers types.

This might need to instead just be documentation only?

I think part of dropping IIS and Windows support is that we can't test on it. Is it possible, or is there an existing issue, where we can run caddy in gitlab ci?

Yeah I came here to post the same thing as #8, if we can add a frankenphp gitlab environmnet and run that on commit, that would ensure that what we're providing will actually work when people try to use it.

Hi,

FrankenPHP author and Caddy maintainer here.

At Les-Tilleuls.coop, we have internal GitLab CI pipelines that use FrankenPHP.
Symfony has a GitHub Actions workflow using it too: https://github.com/symfony/symfony/blob/4b659cbe4c140e5fb73961397e18964b...

This should be straightforward to add. Let me know if I can help doing this!

If it can help pushing this issue, here is some quick perf tests of Drupal with frankenphp : https://www.iosan.fr/en/blog/what-does-frankenphp-and-drupal-have-say-ab...

Summary is :
NGINX+PHP-FPM : ~ 191ms
FrankenPHP : ~ 10ms

The results in https://www.iosan.fr/en/blog/what-does-frankenphp-and-drupal-have-say-ab... are a bit confusing - if frankenphp is responding in about 1/20th the time, why is it only serving 565 calls vs. 483? You would expect it to be able to serve a much higher number of calls in the same time. Or if it's similar to the n500 in apache bench, you'd expect the calls to be identical.

It's also not clear if this is testing anonymous users or not, average response time of 191ms with Drupal's internal page cache would suggest a misconfiguration somewhere, it should be <10ms if page caching is working. If it's auth users or with page caching disabled, that would make more sense, but I'd still want to know why the number of requests served doesn't differ as much as the response time.

@catch i agree with you, the number of calls does not reflect the difference of response time.
As explained in blog post, both tests are done with minimum configuration :

- a fresh drupal installation with default umami profile.
- no differences between the two jmeter scenarios

I don't have dedicated servers to make real tests, but i can at least confirm i tested in the same way both stacks.
I'm not expert about jmeter, so if someone want to improve those tests, feel free to contribute !

Tests have been done with anonymous users, requesting home page.

I had a quick re-read of the post to see if there answer for the discrepancy was in there:

and searched for the "Vegan" string on performance tests for 600 seconds with an HTTP call (no HTTPS).

This might explain things - say nginx could serve 30 x 1 second requests per second, that's 18,000 requests in 600 seconds.

But if frankenphp can only serve 10 x 100ms requests per second, that'd be 6,000 even if each individual request is ten times as fast.

Possible changes to make to the load test:
1. Create a regular authenticated user in Umami, and get jmeter to add their session cookie to the request (I haven't used jmeter for years now but there must be docs for this). This means a lot more PHP to execute, making any network traffic variation less of a variable.

2. Go down to single concurrency, so it's how many end-to-end requests can be done in the 600s, this will eliminate any concurrency limits that might be in place in server config and a lot of hardware/resource bottlenecks too.

This issue feels it should have a meta for discussing the merits of frankenphp and another issue for gitlab ci, so we can focus this issue on the caddyfile.

For CI it needs another image a-la https://git.drupalcode.org/project/drupalci_environments/-/tree/dev/php/...
Then it will be much easier to add extra CI run

PS: Let's file issue to project/drupalci_environments

Would it be possible to hack on this in an experimental GitHub repo using GitHub actions without having to wait for a CI image?

@catch i figured out where i was wrong.

I misconfigured my Drupal settings for the nginx+php-fpm (no cache).

I update the blog post to fix this.

I make tests again as anonymous with all caches disabled (Drupal + twig) to enforce calculation.
And another as anonymous with all caches enabled.

Jmeter has been configured to launch only one thread at time, with no delay between two threads.

Summary is :

No cache :
NGINX+PHP-FPM : ~ 202ms
FrankenPHP : ~ 226ms

Cache enabled :
NGINX+PHP-FPM : ~ 5.43ms
FrankenPHP : ~ 6.36ms

Otherwise, something is still wrong since there is a big difference between the time with/without cache and the number of request with/without cache.

I think you mentioned some of the core test failures are due to different headers being sent by frankenphp vs. apache, I think I've seen this with nginx and ddev too at least a couple of times too.

I've been running core's functional tests with FrankenPHP and this Caddyfile on my localhost and getting pretty good results. At first there were many failing tests due to the self signed certificate, but disabling HTTPS resolved those. Currently I'm down to the below list of fails:

Unexpected status code

• \Drupal\Tests\ckeditor5\Functional\ImageUploadTest::testUploadFileExtension - getting 403 instead of 422
• \Drupal\Tests\ckeditor5\Functional\ImageUploadAccessTest::testCkeditor5ImageUploadRoute - getting 403 instead of 201
• \Drupal\Tests\ckeditor5\Functional\ImageUploadAccessTest - getting 403 instead of 422
• \Drupal\Tests\file\Functional\DownloadTest::testFileCreateUrl - getting 404 instead of 200
• \Drupal\Tests\rest\Functional\Views\StyleSerializerTest::testResponseFormatConfiguration - getting 200 instead of 406
• \Drupal\Tests\system\Functional\CsrfRequestHeaderTest::testRouteAccess - getting 200 instead of 403
• \Drupal\Tests\system\Functional\System\HtaccessTest::testFileAccess - getting 200 instead of 403

Unexpected http headers

• \Drupal\FunctionalTests\WebAssertTest::testResponseHeaderExists - Failed asserting that the response has a 'Null-Header' header.
• \Drupal\FunctionalTests\WebAssertTest::testResponseHeaderDoesNotExist - AssertionFailedError not thrown
• \Drupal\Tests\jsonapi\Functional\MessageTest::testPostIndividual - unexpected allow header value
• \Drupal\Tests\system\Functional\Routing\RouterTest::testFinishResponseSubscriber - no vary header
• \Drupal\Tests\system\Functional\System\HtaccessTest::testSvgzContentEncoding - missing gzip for x-encoded-content-encoding

Unit test fails

• \Drupal\Tests\Scripts\TestSiteApplicationTest::testInstallScript - BadRequestHttpException
• \Drupal\Tests\Scripts\TestSiteApplicationTest::testInstallInDifferentLanguage - non-zero exit code

Other issues

• \Drupal\Tests\mysql\Functional\Mysql8RequirePrimaryKeyUpdateTest::testDatabaseLoaded - missing db privileges
• \Drupal\Tests\update\Functional\FileTransferAuthorizeFormTest::testViaAuthorize - page missing "Files were added successfully" message
• \Drupal\Tests\update\Functional\UpdateUploadTest::testUploadModule - Current page is "/core/authorize.php/core/authorize.php", but "/core/authorize.php" expected.

way less failures than i feared. I have a problem installing a site too so that makes sense the tests fail, thanks for testing that!

I hadn't run FunctionalJavascript tests yet but now that I've started to run some they seem to mostly be passing, only failing on similar issues to the Functional tests.

Started having a look at the first of those fails mentioned in #29. It's expecting a 422 but getting a 403. The interesting thing is that if I repeat the test 10 times it passes 5 five times. So it's definitely capable of sending a 422, but for some reason it's not consistent.

$ phpunit -c core/phpunit.xml.dist core/modules/ckeditor5/tests/src/Functional/ImageUploadTest.php  --filter=testUploadFileExtension --repeat=10
PHPUnit 9.6.19 by Sebastian Bergmann and contributors.

Testing 
F.FF...F.F

It's possible that some of random files created by $this->getTestFiles are causing issues and others aren't. Would need to investigate a little further and try to remove the randomness.

I'm nowhere regarding the gitlab ci stuff in #3438767: Support FrankenPHP as a webserver I don't really have time to spend on it and I'm not even sure where to start so any help would be welcome :)

I've also been thinking about gitlab ci but need some more time. Perhaps as a starting point we could just add the frankenphp static binary to an existing image (like drupalci/php-8.2-cli) and work to build our own image over time

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Not sure the Caddyfile supports running in a subdirectory. I have tests running and somewhat passing in Github Actions at https://github.com/mstrelan/drupalci-frankenphp but if I move to a subdirectory it doesn't work. Also struggled to get this working on Drupal Gitlab CI, I think mostly due to file permissions and ownership, but I'll post more about that on #3438767: Support FrankenPHP as a webserver.

btw PHP 8.3.11 fixing lots of memory leaks so it makes sense to rebuild the image, gonna add drupalci image this weekend based on https://github.com/mstrelan/drupalci-frankenphp

Hi there, coming from here https://github.com/dunglas/frankenphp-drupal/issues/1#issuecomment-23439... just to say that we are using FrankenPHP on a few Drupal projects in production for a few months now. We had some issues related to BigPipe as FrankenPHP has a known issue with PHP Fibers, but appart from that things are running smoothly. We can not use the worker mode yet as the Symfony Runtime is not supported by Drupal as of now.

FrankenPHP got some good performance boosts this summer so the performance tests that were done might be giving different results now.
I'm not sure how to help here to make things go forward.

EDIT: I've created an example repo of what kind of configuration we are using. It is a dockerized Drupal 11 with FrankenPHP. See https://github.com/Renrhaf/drupal11-frankenphp

As tests running in subdirectory most of them failed, so config should be tuned for CI

looking at the failed test

cURL error 7: Failed to connect to localhost port 80 after 0 ms: Couldn't connect to server

this seems like the frankenphp server not started properly.

both brotli and zstd supported out of box https://externals.io/message/127347

Looks it mostly fixed https://github.com/php/php-src/issues/13648#issuecomment-2900612456

https://thephp.foundation/blog/2025/06/08/php-30/ - 30 years of PHP: FrankenPHP is now part of the PHP organisation

Added 8.5-ubuntu-frankenphp:dev image also added note about subdir but looks it's not enough yet

This would allow us to test #3570909: Support early hints for fonts - functionality isn't yet supported in core PHP.