Mail-in-a-Box alternative.
When one-command-and-done isn't enough.

At a glance

Side-by-side, current as of May 2026.

The verdict

How they differ

Different products for different audiences

Mail-in-a-Box's README is explicit: "no user-configurable setup options." That's the value proposition. The project deliberately optimises for one-command personal email sovereignty over flexibility. If you're an individual reclaiming email from Gmail, that's exactly what you want.

Vectis Mail sits in a different category. The audience is teams, SaaS, and multi-domain operators who need a real transactional sending API, inbound webhooks, multi-tenancy, and config-as-code. Comparing the two on the same table is useful for the migration question, but understand what each product is for.

API surface

Mail-in-a-Box exposes a minimal REST API for control-panel operations: creating users, managing aliases, setting forwards. There's no transactional sending API, no inbound webhooks, no domain-scoped keys, no per-domain rate limiting. SMTP submission is the only programmatic send path.

Vectis Mail has 40+ endpoints covering sending (single + batch with attachments), inbound webhooks (full body parsing, HMAC-signed payloads, exponential-backoff retry), mailbox/alias/domain CRUD, analytics, audit logs, and admin operations. Domain-scoped API keys with per-domain rate limits make Vectis usable as a real transactional service: a SendGrid-shape API that you self-host.

See the API Reference for the full surface.

Multi-tenancy + multi-domain

Mail-in-a-Box is single-org-shaped. You can run multiple domains on one box, but the control panel, the user model, and the operational shape all assume one organisation. Vectis Mail is multi-tenant from the database up: tenants, domains, mailboxes, and API keys are isolated at the database row level. If you're running mail infrastructure for multiple brands or customer subdomains, that's a structural difference, not a config tweak.

Configuration model

Mail-in-a-Box's configuration lives in the web control panel and on-disk files managed by the install script. There's no declarative config surface. Every change is a UI click or a manual file edit, and the upgrade path documented as "fresh OS only" means modifying the box voids the supported upgrade story.

Vectis Mail uses a single config.yaml as the source of truth. vectis apply diffs the desired state against running state, regenerates affected service configs (Postfix, Dovecot, Rspamd, Traefik), and reloads only what changed. Terraform, Ansible, or your own automation can manage Vectis Mail declaratively via the same REST endpoints the CLI uses.

Update + rollback

Mail-in-a-Box upgrades by re-running the setup script: straightforward when the box is unmodified, fragile when you've customised anything. There's no automatic snapshot, no health-check gate, no rollback. If a release breaks something, recovery is whatever you do manually.

Vectis Mail's orchestrator runs a 6-phase pipeline:

1. Snapshot — Postgres dump + Compose backup taken before any change.
2. Migrate — forward-only SQL migrations applied with row-level locking.
3. Pull — new container images pulled and verified.
4. Deploy — services recreated with the new images.
5. Health-check — Postfix, Dovecot, Rspamd, API, Traefik all probed for liveness + actual mail-handling readiness.
6. Complete — change locked in, snapshot retained for the rollback window.

Any phase failure triggers automatic rollback to the snapshot. See Installation for the full update model.

Calendar + contacts

Mail-in-a-Box bundles Nextcloud for CalDAV and CardDAV; calendar and contacts work out of the box. Vectis Mail doesn't ship calendar/contacts yet; that's on the Phase 4 roadmap. If you actively use CalDAV/CardDAV, that's the most significant functional gap and the strongest reason to either stay on Mail-in-a-Box or pair Vectis Mail with a separate groupware deployment.

License + pricing

Mail-in-a-Box is CC0-1.0: public domain, the most permissive license possible. Zero lock-in, zero strings, no commercial edition, no paid support, donations welcome.

Vectis Mail is dual-licensed: BSL 1.1 for the core (free Starter: up to 3 domains, 25 mailboxes per domain, full API, webhooks, monitoring, backups) and a commercial Pro license at $29 USD/tenant/month (unlimited domains and mailboxes, per-domain analytics, OIDC SSO, priority support, one subscription covers unlimited installs). See pricing.

Migrating from Mail-in-a-Box to Vectis Mail

The mail-data layer migrates cleanly (both products are vanilla Postfix + Dovecot). The calendar/contacts and control-panel-config layers need manual export.

1. Stand up Vectis Mail on a fresh VPS following the installation guide. Configure your domain(s) but leave DNS pointed at Mail-in-a-Box for now.
2. Sync mailbox data with imapsync or doveadm backup — same Dovecot underneath, maildir transfers directly.
3. Generate new DKIM keys on Vectis Mail and publish them to DNS alongside the existing Mail-in-a-Box keys. Run both in parallel during the switchover.
4. Export Roundcube settings (per-user filters, signatures) from Mail-in-a-Box Roundcube and re-import into Vectis Mail Roundcube.
5. Re-create domains, mailboxes, aliases, and forwards via Vectis Mail's CLI or API. The Mail-in-a-Box control panel doesn't export config-as-code, so this is a manual transcription.
6. Export Nextcloud calendar + contacts to iCal/vCard if you use them. Vectis Mail can't import these — you'll need a separate CalDAV/CardDAV destination from this point. This is the most significant step if calendar is part of your daily use.
7. Cut DNS over: update MX to point at the Vectis Mail server. Mail starts flowing through Vectis Mail as DNS propagates.
8. Verify + decommission: watch logs for a few days, then decommission Mail-in-a-Box.

Realistic timeline: an afternoon for a small personal install without calendar, longer if Nextcloud calendar/contacts are central to your use.

Frequently asked questions