An Unraid-first, single-container deployment of SimpleLogin for people who want the self-hosted alias stack without manually wiring separate Postgres, Redis, and Postfix containers.
simplelogin-aio packages the web UI, background jobs, inbound email handler, Postfix, PostgreSQL, and Redis into one image with persistent Unraid appdata paths. The wrapper is opinionated for a reliable first boot, but it does not hide the real complexity of self-hosted mail: DNS, inbound port 25, SPF/DKIM/DMARC, and sender reputation still matter.
- SimpleLogin web UI on port
7777 - Background job runner
- Inbound email handler
- Embedded PostgreSQL
- Embedded Redis
- Embedded Postfix for inbound and outbound mail routing
- Unraid CA template at simplelogin-aio.xml
If you want the simplest supported path:
- Install the Unraid template.
- Set
URL,EMAIL_DOMAIN,SUPPORT_EMAIL, andFLASK_SECRET. - Pick a relay mode if your ISP blocks outbound TCP 25.
- Forward inbound TCP 25 from your router/firewall to the Unraid host.
- Start the container and wait for first-boot initialization to complete.
- Create your first account in the web UI, then disable registration in Advanced View if you want a private instance.
- Add the DNS records from docs/simplelogin-setup.md.
For most users, that is enough to get a working instance online.
This repo is deliberately not a stripped-down "toy" wrapper. The template now tracks the full upstream self-hosting environment surface from SimpleLogin's official example.env, plus AIO-specific relay controls. In Advanced View you can:
- move PostgreSQL or Redis out of the container with
DB_URIorREDIS_URL - override alias domain behavior and onboarding rules
- configure GitHub, Google, Facebook, Proton, and generic OIDC auth
- enable hCaptcha, HIBP, SpamAssassin, Plausible, and Sentry
- provide AWS, Paddle, and Coinbase settings
- mount
/custom-assetsfor custom words files, OpenID keys, Paddle public keys, or other file-based upstream settings
The wrapper still defaults to the internal bundled services so beginners are not forced into a multi-container setup on day one.
The official SimpleLogin docs describe several major capabilities that are configured inside the running app after deployment, not through extra container env vars. Once this container is up, those app features are still available without adding more containers for core infrastructure:
- custom domains and alias domains
- catch-all behavior and mailbox routing
- reverse aliases / reply flow
- multiple mailboxes
- alias directories and organization features exposed by the app UI
- login methods such as social auth, Proton auth, and generic OIDC when their related env vars are set
In other words, the template is responsible for exposing deployment-time and integration-time configuration, while the SimpleLogin web UI still handles normal application-level features after first boot.
- Upstream SimpleLogin container support is currently
linux/amd64only, so this wrapper publishes amd64-only images. - First boot initializes PostgreSQL when
DB_URIis unset, starts Redis whenREDIS_URLis unset, writes the runtime.env, appliesalembic upgrade head, then runsinit_app.py. /appdatais the main persistent volume. It stores PostgreSQL, Redis, uploads, DKIM keys, generated OpenID keys, and other runtime state./pgpis the optional persistent GnuPG home./custom-assetsis an optional advanced mount for file-based upstream settings.- DKIM keys are persisted under
/appdata/dkimand symlinked into the in-container paths the app expects.
- Wrapper releases use the upstream version plus an AIO revision, such as
v4.80.1-aio.1. - The repo monitors upstream releases and image digest changes through upstream.toml and scripts/check-upstream.py.
- Release notes are generated with
git-cliff. - The Unraid template
<Changes>block is synced fromCHANGELOG.mdduring release preparation. mainpublisheslatest, the pinned upstream version tag, an explicit AIO packaging line tag, andsha-<commit>.- When Docker Hub credentials are configured, the same publish flow can push Docker Hub tags in parallel with GHCR.
See docs/releases.md for the release workflow details.
Local validation is built around:
- XML validation for the audited template surface
- shell and Python syntax checks
- local Docker build on
linux/amd64 - end-to-end smoke test coverage for first boot, health, SMTP readiness, restart, and persistence
- Repo issues: JSONbored/simplelogin-aio issues
- Upstream app: simple-login/app
If this work saves you time, support it here: