CamelMailer
DocsAPISDKsTemplatesHow-to

Migrate from Postal

CamelMailer began as a ground-up Rust rewrite of Postal and deliberately kept its proven protocol behaviour. Migration is mostly config and endpoints; the concepts carry over.

What is compatible

  • Config files: an existing postal.yml loads unchanged, since the postal: group is accepted as an alias for camelmailer:, and POSTAL_CONFIG_FILE_PATH still works.
  • Concepts: organizations → servers → domains / credentials / routes / webhooks map one to one.
  • SMTP behaviour: the state machine is a line-for-line port, verified against the original test suite.

What changed

PostalCamelMailer
Ruby on Rails + MariaDB (one DB per mail server)One Rust binary + one PostgreSQL (row-level security per tenant)
Legacy API (v1) + Admin APIOne v2 surface: /api/v2/server, /api/v2/admin, /api/v2/auth
Multiple processes/roles via bin/postalSame idea: camelmailer web-server | smtp-server | worker | initialize
Web UI (Rails)Next.js dashboard + this docs site

A pragmatic migration

1. Stand up CamelMailer next to Postal (fresh Postgres).
2. Recreate orgs/servers/domains via the management API (scriptable).
3. Publish the new DKIM record alongside the old one.
4. Move senders over credential by credential while both systems run in parallel.
5. Watch stats/bounces for a week, then decommission Postal.

Message history does not migrate, so keep the Postal instance readable until its retention window has passed.

Postal itself remains a fine project (MIT, and credited in our open-source page). Migrate when you want the single-binary operations story, the Postgres consolidation, and the transactional-only focus.