Hello,

While its not ideal, copying these two files into your project should do the trick -

https://gist.github.com/brody192/fcc1136b61c3de20609fa91ee384d47c
https://gist.github.com/brody192/ed12b50fd39e373a28d75f25b100a87d

Thanks you for the quick response, that does seem to do the trick!

Is it correct that the nginx configuration you provided is based on this template: https://github.com/railwayapp/nixpacks/blob/main/src/providers/php/nginx.template.conf, with only client_max_body_size added? Just so I know how to keep that file updated in the future.

Indeed too bad there isn't an easier way to do this, but I'm glad there is at least a way!

Yes that's correct, my nginx conf file is just that with the extra parameter!

Hi again!

Unfortunately when trying to implement this in a Laravel application, I still get a 413 error.

PHP Configuration

While debugging, I discovered that there are two folders with the php.ini file. The command you provided used the first result, while it was the second one that was needed for me. I simply changed head to tail to fix that. I can now confirm that the values are set correctly in the deployed application using ini_get('post_max_size') and ini_get('upload_max_filesize'). So the PHP configuration doesn’t seem to be the problem anymore.

NGINX configuration

I also added the template.nginx.conf file you provided (also tried as nginx.conf). However, I’m not sure how to confirm that the client_max_body_size is set correctly as a result of this. Is there a way I can see that?

Project info

This is the nixpacks.toml I'm currently using:

[variables]
UPLOAD_MAX_FILESIZE = '100M'
POST_MAX_SIZE = '100M'

[phases.setup]
cmds = ['UPLOAD_INI_PATH=$(find /nix/store/*-php-*/lib -name php.ini -print0 | tail -z -n 1 | rev | cut -c 9- | rev)/upload.ini; echo "upload_max_filesize=${UPLOAD_MAX_FILESIZE};" >> $UPLOAD_INI_PATH; echo "post_max_size=${POST_MAX_SIZE};" >> $UPLOAD_INI_PATH']

And this is the start script for the application, as per the Laravel guide:

#!/bin/bash
# Process the Nginx configuration template and start Nginx
node /assets/scripts/prestart.mjs /assets/nginx.template.conf  /nginx.conf && (php-fpm -y /assets/php-fpm.conf & nginx -c /nginx.conf)

If you need more information, please let me know. Do you have any other ideas about what might cause this, or how I can go about debugging? Thanks in advance!

Can you provide a new link to your project and service in question, along with the environment name

Of course!

The service is called 'Site', there is only a 'production' environment in the project currently. Here is a link to the latest deployment:

https://railway.com/project/1d9ded7d-12f5-43eb-b4c6-99e9f32ae7e0/service/7d283bc1-9b89-422f-952a-5dee7c6356c5?environmentId=74d6a525-ee2f-4104-9743-a6c49c69a280&id=5775ed23-ffee-4df6-ab7f-7921223961a7#details

Let's start off by correctly naming the nginx config to nginx.template.conf

Apologies! That was still from my debugging (I found the nginx.conf name in the Nixpacks documentation). The file is named nginx.template.conf again and includes the client_max_body_size 100M; line. The PHP configuration still seems to be working.

Unfortunately the 413 error still persists.

Is there something I can do to help you reproduce the error? I can create an unauthenticated endpoint in the application, or perhaps setup a new empty Laravel application on Railway?

You aren't trying to upload a file thats > 100MB are you?

You also have a Cloudflare Proxy, perhaps the limit is now from Cloudflare? are you sure NGINX/PHP is returning the latest 413 that you are getting?

The request I'm sending is about 2.6 MB (of JSON data). I've disabled the CloudFlare proxy for now. From what I could find their limit is about 100MB, although I couldn't find an official source on that.

The error still remains unfortunately. To me it seems like the error is generated by NGINX, not PHP. From errors generated by the PHP application I would expect a JSON response, instead this is the HTTP response I get:

HTTP/1.1 413 Request Entity Too Large
Content-Length: 183
Content-Type: text/html; charset=utf-8
Date: Tue, 21 Jan 2025 18:09:46 GMT
Server: railway-edge
X-Railway-Request-Id: 1NUaA...63535
Connection: close

<html>
<head><title>413 Request Entity Too Large</title></head>
<body>
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx/1.26.2</center>
</body>
</html>

From what I can see the NGINX configuration seems to be fine as well. I added the following command to the install phase, to output the NGINX configuration, and that does seem to include the client_max_body_size...

node /assets/scripts/prestart.mjs /app/nginx.template.conf /nginx.conf && nginx -c /nginx.conf -T

If you have other ideas for me to try, please let me know!

I don't have any ideas, but at this point I will have to ask for a minimal reproducible example, something as simple as a single index.php file with a form that accepts an uploaded file and shows me the 413 message.

Alright, I've been working on making the problem reproducible, and I think I've got it. I couldn't reproduce the problem with a standard PHP application, only when I had a Laravel project. You can see the problem deployed here. It seems like the run command provided in the documentation was causing the issue. I am able to fix the problem simply by not setting a custom start command.

The command from the documentation:

php artisan migrate --force && node /assets/scripts/prestart.mjs /assets/nginx.template.conf  /nginx.conf && (php-fpm -y /assets/php-fpm.conf & nginx -c /nginx.conf)

The default command provided by Nixpacks, seen in the deployment build log:

node /assets/scripts/prestart.mjs /app/nginx.template.conf /nginx.conf && (php-fpm -y /assets/php-fpm.conf & nginx -c /nginx.conf)

As you can see the default command uses a different path for the nginx.template.conf file, which is probably why the configuration change wasn't picked up. Of course, the command from the documentation also includes a migration step, but that should ideally be moved to the pre-deploy command nowadays anyway. So using the default command seems fine to me.

I've applied this change to the original website in question, and that indeed fixed the 413 error!

Would there be a problem with just leaving the start command empty for a Laravel application? If not, is there any chance the Laravel documentation can be updated, or can I help out with that?

Ah I see the issue, I think that guide assumes you didn't provide your own nginx config file, otherwise /assets/ would be correct.

And yes, we will indeed update the guide!

All and all, I'm glad you found a solution!