Deploying Magento2 with Docker: A Step-by-Step Guide

On your own infrastructure, yes, and many merchants run containerised Magento successfully. There is one important exception. If your store is on Adobe Commerce Cloud, Cloud Docker for Commerce is a local development and testing tool that mirrors the cloud pipeline, not the thing that runs your production site. Adobe manages that environment, and your compose file has no role in it. Confirm which situation you are in before designing a deployment process around containers you may not control.

Whatever Adobe supports for your release. Magento Open Source 2.4.9 became generally available on 12 May 2026 with support for 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. Running an unsupported combination in production means security patches may not apply cleanly and Adobe support has no obligation to help. Pin exact versions, never latest, so a rebuild during an incident does not silently change your platform.

Because unpatched Magento gets exploited fast. Sansec found that around 75 percent of Magento and Adobe Commerce stores were still unpatched a week after the fix for CosmicSting, tracked as CVE-2024-34102, and thousands were subsequently breached. Containers help here if you use them properly: rebuilding an image with the patched version and redeploying is faster and more auditable than patching a live server by hand. They hurt if a pinned base image quietly becomes the reason nobody upgrades.

Usually not. Stateless services such as PHP, nginx and Varnish are excellent container candidates because they can be replaced at will. A database is the opposite: it is the state, and it wants stable storage, tuned hardware, backups, replication and a careful upgrade path. Most production teams run Magento's application tier in containers and use a managed database and a managed search cluster. That combination keeps the deployment benefits without putting your only copy of the orders table inside an ephemeral process.

Not in the image and not in the compose file. Anything baked into an image is readable by anyone who can pull it, and image layers keep deleted files. Use your orchestrator's secret mechanism or an external secret manager, inject values at runtime, and keep Magento's env.php generated from those values rather than committed with real credentials. Rotate the Adobe Composer keys, database passwords and API credentials on a schedule, and make sure a leaked repository would not be enough to reach production.

Build the artefact before you switch traffic. Compile dependency injection and deploy static content during the image build or on a separate release path, run database schema and data upgrades once, then move traffic to the new containers and retire the old ones. Magento's maintenance mode should cover only the schema upgrade window, not the whole build. The failure mode to avoid is compiling on the live server, which is slow, memory hungry and leaves the store in a half updated state if it fails.

Media files, the var directory contents you actually need, the database, the search indexes and your logs. Anything a container writes that you would miss after a redeploy must live on a volume, an object store or a managed service. Product images are the classic mistake: written into the container filesystem, they vanish on the next deployment and the catalogue fills with broken images. Object storage or a shared filesystem for pub/media is the standard answer for multi-container setups.

Terminate TLS at a load balancer, a reverse proxy or a CDN rather than inside the application container, and automate renewal. Let's Encrypt certificates are valid for 90 days and are designed to be renewed automatically, so a manual process will eventually expire on a weekend. Make sure Magento knows it is behind a proxy, otherwise it generates HTTP URLs, produces mixed content warnings and can enter redirect loops between the secure and insecure base URL.

As their own containers or scheduled tasks, with supervision and monitoring, never inside the web container. Cron drives indexing, emails, imports and cleanup, and a store where cron has quietly stopped looks fine for hours and then behaves inexplicably. Consumers should be restarted on each deployment, because they hold compiled code in memory and would otherwise keep running the previous release. Alert on both being alive, since neither failure produces a visible error on the storefront.

Container health and restarts, memory and CPU per service, database connections and slow queries, search engine cluster status, queue depth, cron last run time, and application errors from Magento's own logs. On top of that, monitor the storefront from outside with uptime and real user performance data, because a container can be perfectly healthy while checkout is broken. Ship logs off the host, since container logs disappear with the container and the incident you need them for is the one that killed it.

Back up the database, the media files and your configuration repository, then test a restore. The containers themselves need no backup because they are rebuildable from the image and the compose or manifest files, which is exactly the point. What people forget is media, which lives outside the database, and env.php, which holds configuration that may not exist anywhere else. A backup nobody has ever restored is a hypothesis, so schedule a real restore drill.

When you need more than one application node, automated failover or repeatable scaling, and when someone on the team can operate it. For a single store on a single server, Docker Compose with a solid deployment script is honest, understandable and enough. Kubernetes adds real capability and real operational cost, and a poorly understood cluster is less reliable than a well understood server. Choose based on the traffic and the team you actually have, not on the architecture you would like to describe.