Increase the Nginx upload limit on AWS Elastic Beanstalk

On Elastic Beanstalk, put Nginx changes in your application's deployment bundle. Editing an instance's generated nginx.conf is temporary: a later deployment or replacement instance can discard the change.

Amazon Linux 2 and Amazon Linux 2023

Create .platform/nginx/conf.d/upload.conf at the root of the source bundle:

client_max_body_size 50M;

Elastic Beanstalk includes these .conf files in Nginx's http context on supported Linux platforms. Deploy the bundle, for example with eb deploy. A more specific server or location setting can override this inherited limit.

The limit applies to the whole request body. For a multipart upload, allow room for field values and multipart framing in addition to the file itself. Increasing Nginx's limit does not change the application's limits:

• Express's express.json({ limit: '50mb' }) adjusts its JSON parser; it does not configure multipart upload middleware.
• PHP has separate upload_max_filesize and post_max_size settings. The latter must accommodate the complete POST body. Use the PHP configuration mechanism supported by your specific Beanstalk platform rather than assuming an Nginx directory also loads PHP settings.

Legacy Amazon Linux 1 environments

Amazon Linux 1 Beanstalk platforms are retired. For an existing legacy configuration, the old .ebextensions pattern was:

files:
  "/etc/nginx/conf.d/proxy.conf":
    mode: "000644"
    owner: root
    group: root
    content: |
      client_max_body_size 50M;

Treat this as a migration reference. Check that the particular old platform actually includes that file; use .platform for supported AL2/AL2023 proxy customization.

Verify the deployed instance and upload path

eb ssh
sudo nginx -T 2>&1 | grep -n client_max_body_size

# Use an existing test file and your real upload endpoint.
curl -i -F 'file=@/path/to/big.bin' https://example.com/upload

Inspect the surrounding http, server, and location blocks, not only matching lines. nginx -T reads the files currently on disk; deployment and reload logs establish whether running workers accepted them.

Test a permitted request and one just above the intended limit. The absence of a 413 alone does not prove the upload succeeded: verify the application's response and stored object as well.

FAQ

Why do I still get a 413 after deployment?

Check every instance, the matched location, the application's parser, and any earlier proxy or gateway. An ALB with instance/IP targets should not be confused with its Lambda-target body limits. CloudFront, AWS WAF, API Gateway, and other services have their own behavior; identify which component generated the response before changing limits.

How large should the limit be?

Use the smallest value that supports the actual request. For large files, consider a presigned S3 upload so the body does not have to pass through both Nginx and the application. Validate authorization, object limits, and completion handling for that workflow.

Does the configuration differ for a single-instance environment?

The application-bundle customization follows the same platform mechanism. A load-balanced environment adds components and multiple instances that must also be checked; it does not remove the per-instance Nginx limit.

References: Beanstalk proxy configuration, Nginx request-body limit.