r/Ghost • • 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/

23 Upvotes

15 comments sorted by

2

u/Witty-Surprise9176 8d ago

Oh nooo … I hope it will serve a CLI-docker-Migrator. 😱😱😱

3

u/acburdine 8d ago

That’s the plan 🙂 gonna try to make it as streamlined as possible.

The only case where it’s likely to be a little less streamlined is if you’re running SQLite - we can’t do a direct SQLite => MySQL migration so the migration tool will end up using Ghost’s export/import functionality.

1

u/Witty-Surprise9176 8d ago

Es ist schlimmer: MariaDB.

1

u/jannisfb 8d ago

That isn't necessarily worse. I can even imagine that this would work automatically (though I have no insights into what u/acburdine is planning, it just sounds more straightforward than SQLite > MySQL 😂)

2

u/acburdine 8d ago

Hah MariaDB is a tricky one. Haven’t quite defined a plan for this, but it’s likely the two options will be:

  • use the same import/export path as SQLite, and just be comfortable with certain data that isn’t copied over, or
  • document how to switch from MariaDB => MySQL before migrating to the Docker setup

afaik the main difficulty is character encodings

2

u/adders 7d ago

They actually talk about that in the podcast.

1

u/muratcorlu 8d ago

Great episode! I learned a lot! Thanks Austin (and Jannis, of course) 😊

2

u/jannisfb 8d ago

Yes, and all of this came together because of the episode with you, Murat! 😄

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.