Open Source Mail Servers

Deploy MailKite Server with the reference local backend

Choose the pre-1.0 local deployment deliberately, persist SQLite/blobs, and distinguish backend/console startup from protocol-edge readiness.

Reviewed October 25, 2026

MailKite Server is our open-source project. Its current upstream README describes a reference Node.js/SQLite backend, web console, and separate SMTP/submission/IMAP protocol heads. It is pre-1.0 and is not a groupware replacement.

For the scope compared with conventional mailbox stacks, see MailKite Server in our Linux mail-server comparison.

The official self-hosting runbook covers VPS DNS, TLS, and protocol edges, but still contains a historical note saying the local backend has not shipped. For current backend availability, use the README and your pinned release; use the runbook for the edge setup rather than treating local Compose startup as a complete public mail deployment.

Choose the local topology

Review a pinned trusted release, its Compose file, and current component requirements before executing setup.
Configure persistent SQLite/blob storage, backend access, and secrets according to that release. Keep local and hosted backend credentials distinct.
Start the documented backend/console configuration in an isolated environment and secure access before exposing it publicly.
Add only the required protocol edges and their TLS/network settings. Backend HTTP availability does not mean public MX, authenticated submission, or IMAP is configured.

The upstream quickstart uses docker compose up -d for the backend/console and an edges profile for its documented additional edge services. Review exactly what the pinned Compose file exposes rather than assuming every daemon starts with one command.

Verify state and mail readiness separately

Check account/domain configuration, durable state across restart, and restricted administrative access. Then test the selected edge against the local backend contract with controlled fixtures.

Use a dedicated domain and preserve existing MX until TLS, recipient authorization, persistence, and recovery are proven. Older upstream pages may retain historical pre-release notes; use the current README/release contract to resolve availability, not an assumption of full MailKite Cloud parity.