ACELLE MAIL • DOCKER

How to Install Acelle Mail on Docker: Complete Guide

By Abhishek Sharma · Published 2026-08-21 · Last reviewed 2026-08-21

Abhishek SharmaEditor & email infrastructure writerView author profile →

Quick answer: Deploy Acelle Mail with Docker Compose, persistent code/data volumes, MySQL, Redis, PHP-FPM and separate queue workers, following the vendor's current Docker architecture. This guide focuses on the installation layer and deliberately separates application setup from email delivery, authentication and reputation.

Before you start

Acelle Mail is one of the better candidates in this series for a documented Docker deployment because AcelleMail currently publishes a Docker guide with a multi-service Compose architecture. The key lesson is not simply 'put PHP in a container'; it is to keep application code, MySQL data and Redis data persistent, and to separate web PHP-FPM from queue workers and the scheduler so one restart does not stop every background task.

Important: installation instructions can change between software releases. Use the version bundled with your license and compare the vendor's current requirements before copying commands into production. Where this article uses an adapted Caddy or Docker pattern, it is clearly labeled rather than presented as vendor certification.

What you need

Linux host with Docker Engine and Compose.
Acelle Mail package/license.
Persistent volumes.
MySQL.
Redis where used by the current stack.
Nginx or another TLS reverse proxy.
A reliable backup strategy.
SMTP/SES credentials.

Architecture

Internet → Nginx/Caddy → Acelle PHP → MySQL + Redis → worker + scheduler → SMTP/SES

Keeping these layers separate makes troubleshooting easier. If the web dashboard works but campaigns do not send, the problem may be in cron, the queue, the delivery server or the provider rather than in the web server. Conversely, a 502 or 500 error normally belongs to the web/PHP layer.

Step-by-step installation

1. Create the Compose project

Create a directory such as /srv/acellemail and separate folders for PHP, Nginx, secrets and certificates. Keep secrets out of Git.

2. Build the PHP image

AcelleMail's current Docker documentation uses a custom PHP 8.3-FPM image with the PHP extensions required by the wizard, plus Composer and operational tools. Follow the exact Dockerfile for your installed Acelle release.

3. Create persistent volumes

Use a named volume for Acelle code because the current vendor Docker guide explains that its patch flow can mutate application files in place. Use separate persistent volumes for MySQL and Redis.

4. Create MySQL and Redis services

Start MySQL and Redis first, wait until they are healthy, then populate the application volume. Use secrets for database passwords rather than putting them directly in Compose environment values when practical.

5. Add Nginx/Caddy

The current vendor Docker architecture uses Nginx in front of PHP-FPM. If you substitute Caddy, preserve the public directory and FastCGI routing correctly.

6. Populate the application volume

Copy the licensed Acelle package into the named volume using the procedure documented by AcelleMail. Correct file ownership before starting the web installer.

7. Run the web installer

Open the hostname and complete the system checks, database setup and admin account. If extensions or permissions fail, fix the container image/volume rather than patching the live container manually.

8. Run separate workers

The current vendor Docker guide deliberately separates app, worker and scheduler services. This prevents an FPM restart from silently stopping queue processing. Keep this separation in production.

9. Enable HTTPS

Use the documented reverse-proxy/certificate arrangement. The current vendor Docker guide demonstrates a Certbot/Nginx approach; Caddy can be used as an alternative reverse proxy if you understand the differences.

HTTPS reminder: Use a publicly trusted certificate and test redirects, assets, login and tracking URLs after enabling TLS.

10. Configure backups and upgrades

Back up MySQL and the Acelle code volume. Before patching, follow the vendor's Docker-specific upgrade flow and restart app/worker/scheduler together when required.

Post-install configuration

Once the installer finishes, resist the temptation to immediately import a large list and launch a campaign. First configure the sending layer, domain authentication, bounce handling and unsubscribe behavior. Your application can be perfectly healthy while the email infrastructure is not ready for production.

1. Configure the sending service

Use a delivery service or MTA that is appropriate for your sending volume and compliance requirements. Record the exact SMTP/API endpoint, credentials, region and encryption settings. Never publish credentials in screenshots, tutorials, public repositories or support tickets.

2. Authenticate the sending domain

Publish the SPF, DKIM and DMARC records required by your chosen delivery service. If the provider gives you DKIM CNAME records, use those exact values. Avoid creating multiple conflicting SPF records. Start DMARC in a monitoring mode when you are still mapping legitimate senders, then tighten the policy once authentication is verified.

3. Configure bounces and complaints

A campaign system should not keep treating permanently failing addresses as healthy subscribers. Configure the application's bounce/complaint workflow and monitor the resulting logs. If your provider exposes feedback-loop events, connect them where the application supports it.

4. Test with a small list

Send a controlled test to addresses you own at more than one mailbox provider. Check authentication results, rendering, unsubscribe behavior, tracking, bounce handling and queue processing. Only after the end-to-end workflow passes should you increase campaign volume.

Common mistakes to avoid

Installing a PHP version without checking the application's current compatibility requirements.
Using the database root account inside the application.
Making the entire application directory world-writable.
Putting passwords or AWS credentials into a public repository.
Assuming a successful login means scheduled jobs are working.
Sending a large campaign before SPF/DKIM/DMARC and bounce handling are verified.
Treating the application as the email delivery server when it actually relies on an external SMTP/API provider.
Skipping backups before upgrades.

Troubleshooting

Wizard fails extension checks

Rebuild the custom PHP image with the required extensions; do not rely on a bare php:fpm image.

Permission checks fail

Correct the ownership of the named code volume using the PHP container's runtime user.

Queue stops unexpectedly

Check the worker service independently of the web app. Separate workers are an intentional part of the current vendor architecture.

Patch disappears after rebuild

If application code is baked into an image instead of kept in the persistent volume pattern recommended by AcelleMail, a rebuild can replace the patched files.

Database is lost

Check that the MySQL data directory is mounted to a persistent volume and that backups are being created outside the container.

Security checklist

Use SSH keys where possible and disable unnecessary remote access.
Keep the operating system, PHP runtime and application patched.
Use a dedicated database account.
Keep MySQL private unless remote access is explicitly required.
Use HTTPS for the administration interface.
Protect application configuration and secret files.
Back up the database and uploaded/application data.
Test restoring a backup rather than assuming it is usable.
Monitor disk, RAM, CPU, queue depth and application logs.

When should you choose this installation method?

Docker is especially compelling for Acelle because the vendor publishes a current multi-container deployment pattern. It gives you a repeatable stack and clean separation between web, worker, scheduler, database and Redis. It does require more operational knowledge than a simple cPanel install.

Final checklist

☐ DNS resolves to the server
☐ Supported PHP/runtime is installed
☐ Database and dedicated user created
☐ Application installer completed
☐ Correct file permissions applied
☐ HTTPS works
☐ Cron/worker jobs execute
☐ Sending service connected
☐ SPF/DKIM/DMARC verified
☐ Bounce/complaint processing tested
☐ Unsubscribe tested
☐ Backup created and restore plan documented
☐ Small end-to-end test campaign completed

Related installation guides

Sources & references

This guide uses the following vendor or platform documentation. Where a deployment method is an adaptation rather than vendor documentation, that distinction is stated in the article.

Editorial note: This guide was reviewed on 13 August 2026 for structure, source alignment and internal consistency. Software vendors can change requirements, commands and supported versions; verify the current release documentation before production deployment.