Go beyond default Docker Compose for Magento 2. Learn how to customize containers, services and configs for a faster, tailored dev environment.
On this page
Magento2 is a powerful eCommerce platform, but setting up and optimizing its development environment can be complex. While Docker Compose provides a convenient way to manage Magento2, customizing it to fit your needs can significantly improve performance and workflow.
At Raulji Technologies, we believe in optimizing Magento2 for the best development experience. Yuvraj Raulji, a Magento 2 expert, says:
“Customizing Docker for Magento2 allows developers to enhance performance, add new services, and tailor the setup to their specific project needs.”
In this guide, we’ll walk you through customizing Docker for Magento 2, including custom PHP settings, Varnish integration, SSL support, and performance optimizations.
Why Customize Docker for Magento2?
- Improve performance: Optimize PHP, MySQL, and caching settings.
- Add new services: Include Varnish, Redis, Mailhog, and Elasticsearch.
- Use custom PHP settings: Adjust memory limits, execution times, and extensions.
- Enable SSL support: Run Magento 2 with HTTPS.
Step 1: Customize PHP Configuration
Magento2 requires specific PHP configurations to run efficiently. Instead of using the default PHP settings in Docker, create a custom PHP.ini file.
1.1 Create a Custom php.ini File
- Inside your Magento project directory, create a php.ini file:sh
CopyEdit
mkdir -p custom-config/php
nano custom-config/php/php.ini - Add the following Magento-optimized settings:ini
CopyEdit
memory_limit = 2G
max_execution_time = 1800
upload_max_filesize = 128M
post_max_size = 128M
zlib.output_compression = On
display_errors = On
1.2 Modify docker-compose.yml to Load php.ini
- Update the docker-compose.yml file by adding a volume to the app service:yaml
CopyEdit
services:
app:
image: magento/magento2
container_name: magento_app
restart: always
volumes:
– ./app:/var/www/html
– ./custom-config/php/php.ini:/usr/local/etc/php/conf.d/custom-php.ini - Restart Docker for changes to take effect:sh
CopyEdit
docker-compose down && docker-compose up -d
Step 2: Add Varnish for Full-Page Caching
Varnish speeds up Magento2 by caching pages and serving them quickly.
2.1 Add Varnish Service to
docker-compose.yml
CopyEdit
varnish:
image: varnish:6.5
container_name: magento_varnish
depends_on:
– app
volumes:
– ./custom-config/varnish/default.vcl:/etc/varnish/default.vcl
ports:
– “6081:6081”
2.2 Create a Custom
default.vcl Configuration
CopyEdit
mkdir -p custom-config/varnish
nano custom-config/varnish/default.vcl
Add the following content:
CopyEdit
vcl 4.0;
backend default {
.host = “app”;
.port = “80”;
}
sub vcl_recv {
if (req.url ~ “^/admin”) {
return (pass);
}
}
Restart Docker and enable Varnish:
CopyEdit
docker-compose down && docker-compose up -d
docker exec -it magento_app bin/magento config:set –scope=default –scope-code=0 system/full_page_cache/caching_application 2
Step 3: Enable HTTPS with a Self-Signed SSL Certificate
3.1 Generate SSL Certificate
CopyEdit
mkdir -p custom-config/nginx
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout custom-config/nginx/server.key -out custom-config/nginx/server.crt -subj “/CN=localhost”
3.2 Modify docker-compose.yml to Include SSL
CopyEdit
nginx:
image: nginx:latest
container_name: magento_nginx
restart: always
depends_on:
– app
volumes:
– ./app:/var/www/html
– ./custom-config/nginx/server.crt:/etc/nginx/ssl/server.crt
– ./custom-config/nginx/server.key:/etc/nginx/ssl/server.key
– ./custom-config/nginx/default.conf:/etc/nginx/conf.d/default.conf
ports:
– “443:443”
3.3 Create a Custom Nginx Configuration
CopyEdit
nano custom-config/nginx/default.conf
Add the following:
nginx
CopyEdit
server {
listen 443 ssl;
server_name localhost;ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;root /var/www/html;
index index.php index.html;location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
fastcgi_pass app:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
Restart Docker and configure Magento to use HTTPS:
CopyEdit
docker-compose down && docker-compose up -d
docker exec -it magento_app bin/magento setup:store-config:set –base-url-secure=”https://localhost/”
Step 4: Optimize MySQL Performance
4.1 Create a Custom MySQL Config File
CopyEdit
mkdir -p custom-config/mysql
nano custom-config/mysql/my.cnf
Add these performance optimizations:
CopyEdit
[mysqld]
innodb_buffer_pool_size=1G
innodb_log_file_size=256M
max_connections=200
query_cache_size=64M
4.2 Update docker-compose.yml to Load my.cnf
CopyEdit
db:
image: mysql:5.7
container_name: magento_db
restart: always
volumes:
– ./custom-config/mysql/my.cnf:/etc/mysql/my.cnf
Restart the MySQL container:
CopyEdit
docker-compose restart db
Step 5: Add Mailhog for Email Testing
Magento sends transactional emails, but in development, you don’t want real emails sent. Mailhog captures emails for local testing.
5.1 Add Mailhog Service to docker-compose.yml
CopyEdit
mailhog:
image: mailhog/mailhog
container_name: magento_mailhog
ports:
– “1025:1025”
– “8025:8025”
Configure Magento to Use Mailhog
CopyEdit
docker exec -it magento_app bin/magento setup:config:set –smtp-host=”mailhog” –smtp-port=”1025″
Now, visit http://localhost:8025 to see captured emails.
Final Thoughts
Customizing Docker for Magento2 improves performance, security, and workflow efficiency. At Raulji Technologies, we use these optimizations in real-world projects to enhance Magento development. Yuvraj Raulji highly recommends these Docker customizations to Magento developers.
Next Steps: Stay tuned for more Magento2 Docker optimizations, including scaling with Kubernetes and CI/CD integration.
Frequently Asked Questions
Answers to the questions we hear most often.
Do these customisations still apply to the current Magento stack?
The techniques do, the version numbers have moved. Magento Open Source 2.4.9 reached general availability on 12 May 2026, and Adobe's supported stack for it lists PHP 8.5, Composer 2.10, MySQL 8.4 or MariaDB 12.3, OpenSearch 3, Valkey 9, RabbitMQ 4.3, Varnish 8 and nginx 1.30. So a Varnish customisation is now against Varnish 8, a cache customisation is against Valkey rather than Redis, and search tuning targets OpenSearch rather than Elasticsearch. Update the tags before copying any configuration snippet.
Should I mount configuration files or bake them into a custom image?
Mount what you tune often, bake what must be identical everywhere. A php.ini fragment or an nginx server block that you are actively adjusting is easier to iterate on as a mounted file, since a restart picks it up. Anything that changes behaviour the application depends on, such as an installed PHP extension or a locale, belongs in a Dockerfile so it is built once and cannot be missing on a colleague's machine. Mounted configuration that nobody remembers to copy is a classic source of works-on-my-machine bugs.
Which PHP settings actually matter for Magento?
Memory limit first, because Composer, dependency injection compilation and static content deployment are memory hungry and fail with an exhausted-memory error rather than a helpful message. Plan on at least 2 GB for CLI operations. Then OPcache, which caches compiled PHP and is the single largest performance setting on a Magento site, along with a generous realpath cache because Magento touches an enormous number of files per request. Max execution time and upload limits matter for admin imports. Everything else is fine tuning.
Should I enable the PHP JIT for Magento?
It is unlikely to help. JIT accelerates long running numeric and compute bound code, and a Magento request is dominated by database queries, cache lookups, template rendering and I/O. The measurable wins come from OPcache being correctly sized, from Varnish serving repeat pages, and from a properly configured cache backend. Enable JIT if you want to benchmark it on your own workload, but do not expect it to substitute for full page caching, and measure before and after rather than trusting a blog post.
How do I add Varnish to a Docker Magento environment?
Put it in front of nginx, configure Magento to use Varnish as its full page cache, and export the VCL that Magento generates for you from the admin or the CLI rather than writing it by hand. Adobe's 2.4.9 matrix lists Varnish 8. The main local complication is that Varnish will happily serve you a stale page while you are editing code, so keep it behind a Compose profile and start it when you are testing caching behaviour, not while you are building templates.
Why does my browser refuse the self-signed SSL certificate?
Because a self-signed certificate has no trusted issuer, so the browser correctly warns. Clicking through works but breaks anything that checks certificates properly, including some payment sandbox callbacks and service workers. The better approach is a locally trusted certificate authority, which mkcert sets up in one command and which makes your development domain show a valid padlock with no warnings. Several maintained Magento Docker setups already ship this. Never reuse a development certificate anywhere outside your machine.
Why run Magento over HTTPS locally at all?
Because production does, and the differences bite. Secure cookies, mixed content warnings, HSTS behaviour, payment provider redirects, service workers and several browser APIs behave differently over plain HTTP, so a bug that only appears on staging is often just an HTTPS bug you could not reproduce. Setting the base URLs to https locally also stops the endless redirect loops that occur when Magento's stored URL and the URL you actually visit disagree about the scheme.
Which MySQL settings are worth tuning in a container?
The InnoDB buffer pool above all, since it decides how much of your data lives in memory rather than on disk, and Magento's schema is large. After that, the log file size, the maximum allowed packet, which trips over large product imports, and the connection limit if you run many consumers. Do not blindly copy a production my.cnf into a laptop container, because a buffer pool sized for a dedicated database server will starve every other service in your stack and cause confusing failures elsewhere.
Should I still use Mailhog for catching email?
The idea is right and the tool has moved on. Mailhog is no longer actively developed, and Mailpit is the maintained drop-in replacement with the same purpose and a better interface. Whichever you pick, the point is that your development environment should be structurally incapable of emailing real customers. Point Magento's transport at the catcher, then place a test order and read the confirmation in the web interface. This is how you review transactional email templates safely.
How do I add a PHP extension the project needs?
Add it to the Dockerfile and rebuild, do not install it into a running container. Anything you install by hand at runtime disappears the next time the container is recreated, and it exists on your machine but not on anyone else's, which produces the worst class of bug: one that only one person can reproduce. Rebuilding also means the extension is reviewed in a pull request alongside the code that needs it, so the environment change and the feature ship together.
Can I customise this stack to match production exactly?
You can get very close, and it is worth the effort. Match the PHP version and extension set, the database engine and version, the search engine version, the cache backend and the web server, because those are where behavioural differences hide. What you cannot replicate on a laptop is scale: real data volume, concurrency, network latency and a CDN. So use Docker to eliminate version drift as a cause of bugs, and use a real staging environment for anything that only appears under load.
How far should I customise before switching to a maintained setup?
If you find yourself maintaining Varnish VCL, SSL trust, Xdebug toggles, cron, consumers and a version matrix by hand, you are now maintaining a product rather than a project. Setups such as docker-magento, Warden and DDEV already solve all of that and track Adobe's supported versions for you. Build your own to understand the internals, which is exactly what this series is for, then adopt a maintained base and keep your customisations as a thin layer on top of it.
