ACELLE MAIL • VPS

How to Install Acelle Mail on Ubuntu VPS: Complete Guide

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

Abhishek SharmaEditor & email infrastructure writerView author profile →

Quick answer: Install Acelle Mail on Ubuntu with PHP, MySQL, Nginx, HTTPS and the background queue/cron services required for production use. This guide focuses on the installation layer and deliberately separates application setup from email delivery, authentication and reputation.

Before you start

Acelle Mail is a PHP/Laravel-based self-hosted email marketing platform. A VPS installation gives you control over PHP, MySQL, Nginx, cron and optional Redis/queue infrastructure. The key difference from a simple PHP upload is that a production Acelle installation should be treated as an application stack: web requests, scheduled tasks, queue workers, database storage and email delivery all need to be healthy.

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

Ubuntu LTS VPS with sudo access.
DNS hostname.
Acelle Mail license/package.
Supported PHP version and extensions.
MySQL/MariaDB.
Nginx or Apache.
Cron and, where appropriate, Redis/queue services.
SMTP/SES or another delivery provider.

Architecture

Domain → Nginx → PHP-FPM/Acelle → MySQL + Redis/queue services → 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. Prepare Ubuntu

Update the OS, create a sudo user, configure SSH keys and a firewall, and point your hostname to the VPS.

2. Install PHP and extensions

Use the PHP version specified by the current AcelleMail release. The vendor's recent Ubuntu documentation uses PHP 8.3 in its current deployment material; confirm the exact version supported by your package before installing.

3. Install MySQL

Create the Acelle database and a dedicated user. Keep MySQL private and back up the database regularly.

4. Install Nginx

Configure the application root according to the Acelle package's public directory. Laravel-style applications commonly expose a public directory rather than the entire project tree.

5. Upload Acelle Mail

Upload the licensed package, extract it and apply the required ownership/permissions. Do not make the entire application writable to the public web server.

6. Run the web installer

Open the HTTPS installation URL and complete the license, database, admin and application settings. The current Acelle documentation describes a multi-step installer with system checks.

7. Configure queue/cron

Acelle relies on scheduled work for application processing. Follow the version-specific worker/cron instructions and use Supervisor or systemd where the vendor recommends long-running workers.

Cron reminder: Scheduled email applications are not complete when the dashboard loads. Confirm the scheduled jobs actually execute and produce expected logs before sending a real campaign.

8. Configure HTTPS

Use Certbot or another certificate manager and force HTTPS. Make sure the application's base URL is correct.

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

9. Add the sending server

Configure Amazon SES, SMTP or another supported delivery service. The application is the campaign layer; the provider/MTA is the delivery layer.

10. Harden and test

Secure the admin path, enable backups, verify queue workers, send a test campaign, confirm unsubscribe behavior and inspect logs.

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

Installer shows missing PHP extension

Install the extension required by the exact Acelle release and restart PHP-FPM.

500 error

Inspect Laravel/PHP and Nginx logs, then check storage/bootstrap/cache permissions.

Queue does not process

Check the worker service and scheduler. A web dashboard working does not prove that background workers are running.

Database connection error

Verify DB_HOST, database name, user and password; confirm MySQL is listening locally.

Emails do not send

Check the configured sending server and provider credentials, then test the worker/queue path.

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?

A VPS is the most flexible Acelle deployment because you can install the exact PHP/runtime components, manage workers and tune the database. It is a good choice when the application is expected to handle meaningful subscriber or campaign workloads and you are comfortable maintaining Linux.

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.