Deploying on render.com

[mikefrancis]

What happened?

Hi there,

I'm trying to get a pretty standard Laravel app deployed on a Render web service instance.

Here's my Dockerfile:

FROM dunglas/frankenphp

RUN install-php-extensions \
    pdo \
    gd \
    intl \
    zip \
    opcache

RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

COPY . /app

RUN composer install --no-interaction --no-scripts --no-suggest

RUN php artisan config:cache
RUN php artisan route:cache
RUN php artisan migrate --force

# Line below needed otherwise build exits with a permissions error
RUN setcap -r /usr/local/bin/frankenphp

Locally, if I run (from the docs):

docker run -p 80:80 -p 443:443 -p 443:443/udp -v $PWD:/app dunglas/frankenphp

Everything works as expected.

On Render, when I deploy everything seems to build and start correctly, I even get the default Laravel uptime endpoint (/up) returning something positive as the healthcheck passes, however if I try to visit the site in a browser I get the "TOO MANY REDIRECTS" error.

I've tried clearing my cookies, different browsers and tweaking the ports exposed but nothing seems to help. I don't really have anything special set up in the environment as shown below:

I think the issue might be something to do with the default port binding and/or proxying from HTTPS -> HTTP but I don't know enough about this to get it working.

Any ideas welcomed! Thanks in advance

Build Type

Docker (Debian Bookworm)

Worker Mode

No

Operating System

GNU/Linux

CPU Architecture

x86_64

PHP configuration

Unchanged from Docker image

Relevant log output

No response

[dunglas]

Try setting the SERVER_NAME env var to http:// to disable HTTPS.

[mikefrancis]

According to their docs, that seems to be the case:

Render’s load balancer terminates SSL for inbound HTTPS requests, then forwards those requests to your web service over HTTP. If an inbound request uses HTTP, Render first redirects it to HTTPS and then terminates SSL for it.

I've got this Docker image working with Laravel and HTTPS so will maybe just use that until someone who knows more about this than I do gets it working with Render.

[mikefrancis]

Actually, debugging this locally it looks like there's a problem with the environment. Using the same Dockerfile to build an image, and running the following to spawn a container:

docker run --env-file ./.env -it --rm -p 80:80

I get a Laravel "Server error" page. Looking at the Laravel logs, there's no APP_KEY being set, which is present if I exec and run printenv (I think this is also happening on Render too).

[dunglas]

Wasn't SERVER_NAME=:80 enough for HTTPS? According to your quote from the docs, this should be enough.
Regarding APP_KEY, you shouldn't have to use --env-file. If .env contains this env var and is in the container, Laravel should handle it automatically. Be sure to run php artisan optimize in your Dockerfile.

[mikefrancis]

I'm putting HTTPS to one side for the moment as I think the issue is something fundamental to the server not being able to read the environment variables.

.env is present for development in my local environment. If I pass this through when doing docker run --env-file="./.env" I can run printenv from inside/inspect the container and see all the env vars in .env exposed. However, Laravel is not able to read these.

There is no .env file as I understood that Laravel could read system-level env vars? I've never had to manually create a .env file as part of deployment so just wondering if there's something different here regarding FrankenPHP?

For reference, if I use docker run with the volume (-v) option, everything works locally, but obviously I am not able to set the volume on Render.

[dunglas]

No, there is nothing FrankenPHP-specific here. FrankenPHP passes all system-defined env vars to PHP's $_SERVER (you can check this by calling var_dump($_SERVER);. It's likely a Laravel (it is picky with env vars) or PHP config issue.

[mikefrancis]

Ok, have found the issue. Running either:

RUN php artisan config:cache
# or
RUN php artisan optimize

Is making the system-level env vars inaccessible for some reason 🤷 Taking these out and FrankenPHP starts as expected, with Render doing the HTTPS termination.

[bjoycerobo]

I think this is probably caused by when config:cache / optimize is being run.

If those commands run during the Docker image build, Laravel writes the resolved config values into bootstrap/cache/config.php at build time. So the cached config reflects whatever environment existed while the image was built, not necessarily the environment that exists later when Render starts the container.

That would explain why printenv can show the runtime variables inside the container, while Laravel still behaves as if APP_KEY / other config values are missing or stale. The runtime env exists, but Laravel is reading from the already-cached config file.

Laravel’s docs mention that after config is cached, the .env file is no longer loaded and app code should read config values via config() rather than env():
https://laravel.com/docs/13.x/configuration#configuration-caching

So I think one fix is to avoid running these during docker build:

RUN php artisan config:cache
RUN php artisan optimize

and instead run them after the container has started with the real production env vars available, unless you explicitly make those vars available at build time.

I would usually avoid running migrations during the image build for the same reason:

RUN php artisan migrate --force

Migrations should usually happen at deploy/startup time, when the production database env vars are available and the new code that depends on those migrations is being deployed. Otherwise, there could be a significant gap between image build and deploy where the database has already been changed but the old code is still running.

Using a Caddy module such as caddy-exec might be one way to run startup commands, and FrankenPHP documents how to build custom Caddy modules here:
https://frankenphp.dev/docs/docker/#how-to-install-more-caddy-modules