Branded from config
Theme tokens flow into every render so your mail looks like your product, not like a provider default.
Self-hosted. Theme-aware. Rust-fast.
Self-hosted transactional mail with your colors, your templates, and your SMTP provider. One Docker image. Zero vendor lock-in.
Why Mailify
Theme tokens flow into every render so your mail looks like your product, not like a provider default.
Bring your own SMTP provider, run one Docker image, keep your templates and delivery path under your control.
React Email compiles to HTML ahead of time while minijinja placeholders stay live for runtime variables.
Jobs persist in Postgres through apalis, so a worker restart does not eat your outbound mail.
Per-job SMTP override lets one Mailify instance fan out across tenants without leaking shared credentials.
Clear config, predictable routes, and CLI helpers keep setup close to a boring infrastructure service.
Workflow
Mailify keeps the request path boring: exchange an API key for a JWT, send a template id, let the queue handle the actual SMTP work.
# 1. Exchange API key for a short-lived JWT
curl -X POST https://mailify.example.com/auth/token \
-H 'content-type: application/json' \
-d '{"api_key":"dev-secret"}'
# 2. Queue a themed email
curl -X POST https://mailify.example.com/mail/send \
-H "authorization: Bearer <jwt>" \
-H 'content-type: application/json' \
-d '{
"template_id": "welcome",
"locale": "en",
"to": [{"email": "alice@example.com"}],
"vars": {"product_name": "Mailify"}
}' Theme system
Mailify’s default templates read from a theme object at render time, so brand changes stay in config instead of leaking into every mail template.
primaryaccentsuccessSwap colors and logo once, then keep shipping the same templates across environments and tenants.
Open dashboardArchitecture
The API layer receives mail requests, auth validates tokens, templates render branded HTML, and the queue worker ships through SMTP.