increase memory_limit doesn't work in PHP Container in Docker
Stefan Bogdanescu
Founder & Senior Architect · 2026-06-29
# Why `memory_limit` Changes in PHP Container in Docker Don't Seem to Work: A Deep Dive
As senior developers working with containerized applications, we often encounter frustrating issues where configuration changes made within the container environment seem to be ignored by the running application. One of the most common pain points involves memory limits, particularly when dealing with resource-intensive tasks like importing large SQL files in a Laravel application running inside Docker.
This post will dissect why setting `memory_limit` in `php.ini` inside a Docker container often fails to yield the expected results and provide robust, practical solutions for managing memory constraints in your PHP environments.
## The Scenario: Memory Exhaustion in a Containerized Laravel App
You are running a standard setup: a Laravel application served via Nginx, all encapsulated within Docker containers. Your specific issue arises when executing a database import using `DB::unprepared()` with a large SQL file:
```php
$path = public_path('sql/2022_11_16_import_table.sql');
$sql = file_get_contents($path);
DB::unprepared($sql);
```
This operation hits a fatal error related to memory exhaustion, even after you manually adjust `memory_limit` in the `php.ini` files within the container and restart services.
## Diagnosing the Configuration Failure
When developers attempt to modify `php.ini` inside a Docker context, they often run into this paradox. Why does changing the file not reflect the actual runtime limit?
The issue usually stems from one of three core areas: **Configuration Loading**, **Process Context**, or **Layering Conflicts**.
1. **Configuration Loading:** Simply editing `php.ini` doesn't automatically reload that setting for an already running process. PHP processes often load configuration once upon startup, and subsequent runtime changes might be ignored if the specific SAPI (Server API) or FPM pool is not properly reinitialized.
2. **Process Context:** When you execute commands like `php -ini`, you are checking the environment variables loaded *at that moment*, which might reflect a base layer configuration rather than the actively running service's configuration. Furthermore, if you are using PHP-FPM, the FPM pool settings must be correctly aligned with the container's expectations.
3. **Docker Layering:** If your Docker setup uses multi-stage builds or volumes in complex ways, there can be conflicts where the host system’s environment variables or base images override the internal file changes.
## Practical Solutions for Reliable Memory Management
Relying solely on modifying `php.ini` inside a running container is often brittle. A more reliable approach involves leveraging Docker's native configuration mechanisms and PHP-specific runtime settings.
### Solution 1: Use Environment Variables (The Docker Best Practice)
For maximum portability and reliability in Docker, the preferred method for setting runtime limits is by passing environment variables directly to the PHP process or the web server configuration, rather than relying on internal file edits.
If you are using PHP-FPM, ensure your `docker-compose.yml` or `Dockerfile` explicitly sets these values:
```yaml
# Example snippet in docker-compose.yml for PHP service
services:
php:
image: php:8.2-fpm
environment:
# Set the memory limit directly via environment variables
PHP_MEMORY_LIMIT: 2048M # Requesting 2GB, adjust as needed
```
In your application code, you can check these settings dynamically if necessary, although for database operations like `DB::unprepared()`,