Static resources with PHP-FPM when shared volume is not an option?

[MendelYev]

1. The problem I’m having:

Hi, I’m trying to serve a PHP-FPM with Caddy as a reverse proxy. The PHP app and Caddy are in separate Docker containers. I managed to serve .php files with the php_fastcgi directive but I don’t know how to deal with static resources.

As I understand, ideally I should give Caddy access to static files through a shared volume and serve them with file_server. But the .php files and static files are not well organized (mixed in hundreds of directories…) and the dev team won’t change the architecture. It would imply to share a huge directory with the Caddy container, including sensitive data like .pem files.

Also, the app doesn’t have a unique “routing” index.php file. I have to access different ones from URI.

2. Error messages and/or full log output:

None

3. Caddy version:

Caddy v2.6.4

4. How I installed and ran Caddy:

From official Docker container caddy:2.6.4-alpine

a. System environment:

Docker compose (Debian 11 host)

d. My complete Caddy config:

route {
    root * /var/www/html
    php_fastcgi unix//var/run/php/php-fpm.sock
}

This config works only for .php files. Static files are returned a 404 error.

I also tried to send all requests to PHP-FPM with the following directive but it doesn’t work (error 502) : reverse_proxy * unix//var/run/php/php-fpm.sock

Is there a way to serve static files through php-fpm with Caddy?

[francislavoie]

Similarly to Nginx, Caddy is not well suited to those kinds of legacy PHP projects. Since there’s no concept of .htaccess files like in Apache, you would have to add rules to your Caddyfile to reject serving any sensitive files/paths.

Caddy must have access to all the static files and PHP files to properly function.

I strongly recommend starting to work towards having a separate webroot like /var/www/html/public (i.e. public as a subdirectory of the project’s root) and using an index.php script as the routing entrypoint. This is the safest and simplest approach for PHP apps.

I sympathise that this is a difficult goal to work towards though, especially for legacy monolithic projects.

An alternative approach is you could keep running your app with Apache for now, but just reverse_proxy to it with Caddy to let it terminate TLS. Of course that means you’ll still be using Apache to run PHP which has worse performance, but it would at least get you a step further with cert automation.

[MendelYev]

Thank you for your quick reply! I’ll work with the Apache+Caddy approach for now and will wait for dev team to modernize their app.