What if a few of us self-hosters developed requirements to support more than mailgun and got sign off from active maintainers on the implementation approach and then pursued developing it? This seems like something we could divide and conquer and certainly beats complaining why mailgun is the only option for us. If this sounds directionally OK who might be the right folks to collaborate with and start soliciting high level feedback and run plans past? And where is the best place do that? I agree reopening why and how we are here is not constructive and has been discussed.
1 Like
There is a topic about Mailgun Alternative:
Which also leads to work on Github:
I remember there was a discussion about needed an adapter first.
Can’t find it that quickly.
1 Like
Thanks @mulderfrank for pointing me to @Hannah’s feedback. After reviewing her comment about wanting a plan with incremental changes rather than a single PR, I’ve attempted to implement exactly that approach in the hopes that I can help the community move this forward. See updated post below!!
I’ve submitted a 4-PR foundation series that extracts Mailgun to an adapter pattern.
Phase 1: Foundation
Each PR is minimal and focused (following her guidance to “make the smallest change you can find”), includes comprehensive tests, and aims to maintain backward compatibility. After these merge, the architecture should support extending it to support Amazon SES, SendGrid, Postmark, and community-contributed providers.
The foundation is now complete and submitted. Looking forward to feedback from the Ghost team as I trust it will still need additional work!
In the first PR I proposed some potential next steps:
Phase 2: First Alternative Provider
-
PR5: Amazon SES implementation
-
PR6-8: SES configuration & testing
-
Milestone: SES available to users
Phase 3: Community Providers
-
SendGrid, Postmark, SMTP providers
-
Provider selection UI
etc
3 Likes
Hi All! I’m pulling this content, originally attached to someone else’s thread that was unlisted (because it started out unproductive) into its own thread. Otherwise no one but the original posters and mods will be able to see it.
2 Likes
Just a brief note: I got some very useful feedback and am closing the PRs and will re-architect and resubmit an updated series. Extract email provider logic to testable factory (PR 2 of 4) by danielraffel · Pull Request #25246 · TryGhost/Ghost · GitHub
2 Likes
Updated PR Series Submitted for Review
Phase 1: Email Adapter Foundation
-
Added email analytics adapter support with Mailgun implementation (3/4)
-
Added email suppression adapter support with Mailgun implementation (4/4)
Phase 2: Amazon SES Integration for Sending Newsletters
New (config driven) SES Email Provider Newsletter Setting 
- Mailgun remains the default but this replaces it if SES is setup (can only be one newsletter mail config setting)*
Included Setup and Documentation
Reference documentation, and over 70 tests, are included. Complete setup script included in phase 2 for configuring AWS SES to make it easier to review / test using a working Amazon environment.
1. config.development.json.example
• Example SES configuration for local testing
• Demonstrates all three configuration sections: mail, adapters.email, and emailAnalytics
• Uses placeholder credentials for safety
2. config.production.json.example
• Full production-ready configuration template
• Includes database, server, and privacy settings
• Follows SES configuration best practices
3. SES-SETUP.md
• Comprehensive AWS SES infrastructure guide
• Step-by-step CLI commands for:
• Creating SNS topics and SQS queues (with optimized attributes)
• Setting up subscriptions, policies, and configuration sets
• Defining event destinations
• Critical note: Explains why click tracking must be disabled in Ghost
• Lists required IAM permissions, verification commands, and troubleshooting steps
4. DOCS-SUGGESTION-SES.md
• Concise working draft content for Ghost Newsletter Docs
• Focused on technical users
• References the setup script approach
• Mirrors the structure and tone of the Mailgun documentation
I realize Ghost likely has higher-priority work right now, so I continued independently with the goal of making respectful, steady progress. Hopefully, this is a useful contribution to the community. It would be great to have the opportunity to discuss next steps and / or explore merging this upstream if there’s interest from Ghost maintainers. My sense is that the community has long wanted more newsletter provider options, I think it makes Ghost a more valuable platform, and it’s been an honor to help move that forward.
I wrote to one of the PRs but want to mention same comment here as well:
I don’t think Ghost needs to have AWS SES adapter built-in, unless Ghost core team really uses it. Otherwise maintaining those adapters will be an issue for the core team.
I think having an adapter mechanism would be enough for Ghost core. And self-hosters can use a 3rd party adapter to add SES or other providers to their Ghost sites.
In addition to that, I’m curious if you are able to test and use those adapters with SES in some of your Ghost sites? You created tons of PRs with many changes in a very short time range. I mean, you are as fast as my AI colleagues. But my AI colleagues don’t really test if it really works. I’m doing heavy lifting part by testing their solution and it takes quite much time. How do you manage this?
3 Likes
There are 70 tests and I can confirm SES is working on my site. I built this in two phases supporting Mailgun as the first adapter and Amazon SES as the second. I trust the maintainers of Ghost can decide what’s right for the community. It’s available to those who are interested and I am prepared to help support it. The first PR explains the logic behind the approach which was guidance from @ErisDS who is the Ghost CTO:
“Make the smallest change you can find that moves the codebase towards having mailgun bulk mail be an adapter, rather than built-in”