What this is for#
When you self-host AcelleMail, your subscribers' personal data lives in your database on your server — not on a third-party SaaS. That's the privacy win of self-hosting, and it puts encryption decisions in your hands. This article explains, in plain terms, the three places encryption matters and what's actually worth doing — without turning into a sysadmin manual.
If you want the hands-on server commands, those live in your platform's install guide; this page is the map so you know which ones matter and why.
The three layers#
1. In transit — HTTPS on everything#
Every admin login, subscriber export, and API call travels between a browser and your server. Encrypting that path with HTTPS (TLS) is the single most important, lowest-effort layer — without it, anyone on the network can read credentials and subscriber data in the clear.
Your install already sets up a free Let's Encrypt certificate, and AcelleMail can be told to insist on HTTPS (FORCE_HTTPS=true in .env). That's covered as Priority 1 of the Post-Install Hardening Checklist — do it before you put real subscribers on.
2. App secrets — your .env and APP_KEY#
AcelleMail keeps its secrets (database password, mail credentials) in the .env file, and a unique APP_KEY encrypts session data and other sensitive values the app stores. Two things follow from that:
- Protect
.env. It should be readable by the web user and nobody else. (Hardening Priority 1.5.)
- Never regenerate
APP_KEY on a running install — anything already encrypted with the old key becomes unreadable. It's set once at install and left alone.
You don't manage application-level field encryption yourself — the framework handles it via APP_KEY. Your job is just to keep that key and the .env file safe.
3. At rest — disk and backups#
"At rest" means data sitting on disk: the database files, uploaded assets, and your backups. Two practical options, in order of how often they matter:
- Encrypted backups (do this). Backups are the copies most likely to leave your server — to S3, Backblaze, another machine. An off-site backup that isn't encrypted is your whole subscriber list sitting in someone else's storage. Encrypt backups before they leave the box. The Automated Database Backups guide covers the backup routine; encrypting the archive is a step within it.
- Full-disk / volume encryption (for regulated data). If you handle health, financial, or other regulated personal data — or your own policy requires it — encrypting the whole volume the database sits on protects you if the physical disk or a cloud snapshot is ever exposed. Most cloud providers (AWS, DigitalOcean) offer volume encryption as a checkbox when you create the server; turning it on at creation time is far easier than retrofitting it later.
For a typical sender, HTTPS + protected .env + encrypted off-site backups is the right baseline. Full-disk encryption is the next tier up for regulated data.
Where this isn't AcelleMail's job#
Encryption at the OS and database level (TLS certificates, encrypted volumes, encrypted backup archives) is configured on the server, not inside AcelleMail's admin panel — there's no "encryption" screen in the app, and you should be wary of any guide that invents one. The app's part is the HTTPS enforcement and the APP_KEY; everything else is your hosting setup, which your install guide walks through.
Common questions#
Does AcelleMail encrypt subscriber emails in the database? Email addresses are stored so the app can send to them and de-duplicate — they aren't field-encrypted at rest by default (that would break search and sending). Protect them with disk/volume encryption and access control, not field-level encryption.
Is HTTPS enough on its own? It's the most important layer and the one to never skip, but it only protects data in transit. Pair it with protected secrets and encrypted backups for the full picture.
Do I need this for GDPR? Encryption is one of the "appropriate technical measures" regulators expect, but compliance is broader than encryption — see the GDPR Compliance Guide.
Related articles#
