Repository needed

[SharkMachine]

I'm going to be brutally honest, using FrankenPHP on a production system won't be feasible without a repository that will provide updates. The standalone binary is useless without a repository in my opinion.

[withinboredom]

Ultimately, this is up to repository managers; I'd recommend reaching out to them directly via their mailing lists or issue trackers. We also accept PRs.

FWIW, for production: https://github.com/dunglas/frankenphp/blob/main/docs/performance.md#:~:text=In%20production%20environments%2C%20we%20strongly%20recommend%20to%20use%20the%20glibc.

In production environments, we strongly recommend to use the glibc.

This can be achieved by using the Debian Docker images (the default) and by compiling FrankenPHP from sources.

Alternatively, we provide static binaries compiled with the mimalloc allocator, which makes FrankenPHP+musl faster (but still slower than FrankenPHP+glibc).

[SharkMachine]

There are things like PPA and DPA, both use glibc. Having your own PPA and DPA is what I am suggesting.

[withinboredom]

It's not "that easy" otherwise, I, for one, would have done it already. To have a glibc build for a ppa, you need to have a compatible ZTS build installed ... for which one does not exist yet, that I know of. It's a monumental undertaking to maintain all the dependencies and ensure compatibility between everything. It's much simpler to just build it from scratch (aka, Docker).

[SharkMachine]

I've been testing FrankenPHP to replace my current nginx + PHP-FPM setup. Not having a repository and forced to do manual updates is a big no for me. I can understand it is a big challenge for you. I think I'm going to stick with nginx + PHP-FPM until you conquer that challenge.

[withinboredom]

If Ondřej Surý could provide a compatible zts package, we could theoretically build off of it and provide a package easily. The Frankenphp package, by itself, is fairly straightforward. It's building and maintaining zts + all of its extensions and their dependencies that is just too much work. If Ondřej Surý's packages were open source, I'd be happy to contribute, but they are not, AFAICT.

[dunglas]

We provide a Brew repository for Linux and Mac: https://github.com/dunglas/homebrew-frankenphp

Docker images are also automatically updated.

[SharkMachine]

As far as I know, there are no options for Debian based distros. People have been asking for Ondřej Surý to offer a repository.

[withinboredom]

Unfortunately Debian packaging is a bit of a dark art -- I've attempted to create a build, but at the time, the Debian Caddy packages were not a high enough version. It is likely that the Debian team would require this to be the same version of caddy (much like the certmagic library is). On Ubuntu 24.04, caddy is at 2.6.2, so it isn't currently possible to build a package for 24.04-ish.

Looking at Trixie (the next version of Debian), it will include php 8.4 and still Caddy 2.6.2. So, it still probably won't be possible. In any case, Debian doesn't provide php 8.4 ZTS builds...

It looks like only a third party could maintain this.

[nickchomey]

Can caddy upgrade work at all here? https://caddyserver.com/docs/command-line#caddy-upgrade

Perhaps in conjunction with systemd somehow?
https://caddyserver.com/docs/install#static-binaries

https://caddyserver.com/docs/running#linux-service

[dunglas]

The shell script we provide to download the static binary will also automatically update it if run multiple times.

[SharkMachine]

The shell script we provide to download the static binary will also automatically update it if run multiple times.

It's still an extra step you have to do. sudo apt dist-upgrade or sudo yum update will not do it.

[nickchomey]

The shell script we provide to download the static binary will also automatically update it if run multiple times.

What part of the script does the auto updating? All I see is curl/wget and an instruction to move it to /usr/local/bin...

Surely a proper self-update would deal with gracefully switching over from the old binary or docker container to the new one, allowing current requests to finish etc...? Especially if it would work for when we make custom builds.

I do think such functionality would be among the more impactful things that could be implemented for end users. Especially in comparison to shaving off a few more microseconds from serving requests. It's already exceptionally fast - ergonomics and reliability would really move the needle more.

[dunglas]

If you run the script again it overwrite the old version.

I agree that a self-update command would be nice, and packages would be even better. We're working on both but this a lot of work and there a ton of corner cases (help welcome, as usual).

Also, Brew packages support all Linux distributions, including Debian.

[withinboredom]

It's still an extra step you have to do. sudo apt dist-upgrade or sudo yum update will not do it.

This still probably won't get you the latest versions of things. Typically, package managers do NOT release the latest. They choose a version of something and apply any custom patches, then package that version. For example, there was a really annoying rsync bug in ubuntu 24 when the remote was running zsh (it wasn't properly escaping the shell commands). It was fixed in regular rsync, but the patch was never applied in ubuntu's version. So, I had to go hunt down the appropriate mailing list and ask them to apply that patch.

So, just because there is a package, doesn't mean you get the canonical version of that software; they typically cherry-pick whatever commits they want.