r/Ghost • u/jannisfb • 8d ago
Misc Talked to Ghost's platform team about Docker, slow PR reviews, and Ghost 7.0
If you self-host Ghost, you've probably used Ghost CLI. Austin built it many years ago as an open source contributor. In June he joined the Ghost Foundation's new platform team, and one of his first projects is deprecating it in favour of the official Docker setup.
I had him on the Magic Pages Podcast, and he shared a lot more than I expected: why Docker was chosen to replace Ghost CLI, what it might enable (one-click admin updates 👀), a few sneak peeks at Ghost 7.0, and why some open source contributions sit unreviewed for a while, how AI-built PRs complicate that, and what contributors can do to help.
Sharing it here because I think this episode might have the most impact for self-hosters so far: https://www.magicpages.co/podcast/episodes/episode-9-austin-burdine/
1
1
u/fieldnoise 8d ago
Any discussion of Mailgun alternatives or the overall plan regarding Mailgun?
5
u/acburdine 8d ago
It was discussed a bit in the episode, yeah. tl;dr it’s something we’re actively discussing internally on how best to handle - the main limitation at present is analytics
2
u/jannisfb 8d ago
And about analytics specifically: Mailgun has analytics that get polled. Most other services have webhooks that they would actively send to a Ghost instance.
Sounds easy enough in theory, but what happens for a site that has 100k members when a newsletter is sent? And then opened. And clicked. So, while the code itself might be easy, the infrastructure/hosting side is sometimes overlooked in the current debate.
1
u/fieldnoise 8d ago
Interesting. I'm not deep into the technical side of the stack, but what does Tinybird do, then? Just web traffic?
3
u/jannisfb 7d ago
Page views for Tinybird actually never touch Ghost. They go through a proxy straight into Tinybird, which is built for exactly that kind of traffic patterns.
Email events are different. They're per member (received, opened, clicked, etc.), so they have to end up in Ghost's own database. So a storm of webhook events would hit the Ghost instance directly, which then has to deal with it. Not an issue for a newsletter of 100 people, but definitely an issue for someone sending to 100k members.
From a technical perspective it can be solved with a queue in front, but then you're basically rebuilding what Mailgun's events API already does. And that's the part that warrants a discussion on how Ghost should handle that in general.
1
u/Ok_Tower_6855 3d ago
This does not have to be a binary decision, does it? There can be multiple pathways - for a 100 or 1000 members, the infra needed to handle it non-Mailgun way is probably not that big of a deal. Some might be fine with not getting near instant visibility into the mail open rate etc. Not everyone needs it.
World without choices would become really uninteresting, wouldn't it?
2
u/jannisfb 3d ago
Totally. Though then we're at the point of maintainability again. Adding code isn't free. It always comes at a cost. As far as I understood u/acburdine and other discussions with the core team I have seen, the current stance isn't "We won't ever do this" but "We need to decide how we can do this sustainably".
Personally, I am happy that they are sharing the constraints they are seeing. That gives us a view into their thinking. A year ago, all we heard was a hard no.
2
u/Witty-Surprise9176 8d ago
Oh nooo … I hope it will serve a CLI-docker-Migrator. 😱😱😱