Meet the engineer behind self-hosted Ghost

About this episode

Austin Burdine started contributing to Ghost more than ten years ago, back when contributor chat still ran on IRC. Frustrated by how many manual steps self-hosting took, Austin built Ghost CLI and maintained it for a decade. In June 2026 Austin joined the Ghost Foundation's new platform team – and one of the first projects was deprecating Ghost CLI in favour of the official Docker setup. "The longest interview process at Ghost," as the team joked.

Jannis and Austin get into what the platform team actually does, why a 20 MB memory increase matters when you run tens of thousands of sites, and how an idea on the forum turns into a feature. They talk about technical debt in a Node.js code base from 2014, why scoped API keys are harder than they look, how to write a pull request that gets reviewed (open an issue first), and the flood of AI-assisted security reports. Austin also shares where Ghost 7.0 is heading: more extensibility, a public roadmap again, and one-click admin updates for self-hosters.

Chapters

• 0:00 — Welcome — Austin from Ghost's platform team
• 0:20 — Ten years of contributing, then joining Ghost
• 1:48 — Self-hosting Ghost before Ghost CLI
• 3:28 — Retiring the tool you built: the move to Docker
• 4:58 — Working inside the Ghost Foundation
• 6:55 — How a forum idea becomes a feature
• 9:37 — Technical debt vs new features
• 10:52 — A platform team of two
• 12:28 — Pull requests that sit unreviewed
• 13:50 — Making contributions easy to review: open an issue first
• 16:22 — AI-built PRs and a more transactional open source
• 17:45 — Scoped API keys, and why they don't exist yet
• 20:17 — Sharing the roadmap in public again
• 23:06 — Ghost 7.0 and extensibility
• 23:46 — AI and the flood of security reports
• 27:26 — This year's exploits, and why you should update
• 28:56 — What success looks like for the platform team
• 32:19 — For people who don't want to learn Docker
• 35:07 — One-click admin updates
• 37:47 — Payment providers, translations, and what people value
• 39:54 — Wrap-up

Links & mentions

• Austin Burdine on GitHub — for those who do regularly stalk GitHub
• Deprecating Ghost-CLI (& other platform updates) — Austin's forum post announcing the change for Ghost 7.0
• Ghost CLI — the tool Austin built and is now retiring
• Ghost Docker — the Docker Compose setup that becomes the official way to self-host with Ghost 7.0
• Install Ghost with Docker — the official docs
• Ghost forum: Ideas — where feature requests land
• Ghost's security policy — how to report a vulnerability, and what doesn't count as one
• Death by a thousand slops — curl maintainer Daniel Stenberg on AI-generated security reports
• Synaps Media — Murat's managed Ghost hosting, and its scoped API keys
• Episode 7 — Can you be friends with your competitor? — the conversation with Murat that made its way around Ghost's team

Transcript

Jannis: Hi, and welcome to the Magic Pages Podcast, the podcast where we sit down with the people building, hosting, and publishing on Ghost. I'm Jannis, the founder and developer behind Magic Pages, and today I'm here with Austin, one of the platform engineers of the Ghost Foundation. Austin, it's an incredible honor to have you on the podcast. Hello.

Austin: Hi, happy to be here.

Jannis: Well, Austin, for those who don't regularly stalk GitHub, can you quickly tell us a little bit about what you do and how you ended up at Ghost?

Austin: Yeah, so my history with Ghost is fairly lengthy. We joked last week at our team week that I had the longest interview process at Ghost because I started working as an open source contributor for them over 10 years ago when Ghost was still fairly new, when contributor chat was on IRC before it moved to Slack. I started primarily just doing front end and back end contributions based on what issues were available for people to work on. Over time, I noticed that the sort of self-hosting instructions for Ghost were a bit complicated. There was multiple steps involved. None of it was automatic, really easy to mess up. And I was like, what? We could just build a CLI that sort of automates all this, and Ghost CLI was born.

And I worked on that off and on for the last decade and joined Ghost three months ago, roughly, to be on the platform team and take charge of the self-hosting setup and putting some effort into that from a core perspective where it just hadn't been prioritized historically. Funnily enough, one of my first projects is deprecating Ghost CLI. So I joined to kill the thing that I made, but it's been great finally getting to work for Ghost. Finally, all the planets aligned and I was able to make it work.

Jannis: That is quite a lengthy interview process. Yeah. I'm curious, how did self-hosting Ghost work before the Ghost CLI? So I discovered Ghost in 2018 for the first time. And back then, there was already a Ghost CLI, of course. And I thought that was always there, but that was.

Austin: Apparently not the case then. Yeah. Pre 1.0, it was very much a, oh, here we published a zip file to... I don't remember if it was GitHub or some other hosting, like file hosting, where you would download the zip file, unzip it, do the whole NPM install. You had to do all of the database configuration and Nginx or Apache configuration yourself. And then you'd have to maintain some sort of setup. I think Forever was the popular tool at the time.

And then PM2 replaced that, but actually managed the restarting of Ghost and making sure it kept running when you exited your shell session. So it was very much a do-it-yourself sort of thing. Ghost 1.0 is when we launched the CLI. So much more streamlined.

Jannis: Yeah, absolutely. We were like three minutes into the recording and I'm already here with things I never thought about before. I always assumed there was always a Ghost CLI. Well, obviously somebody had to create it at some point. And I would say the entire Ghost community is very thankful to you for that.

Austin: Yeah. I mean, it's impressive that it's still maintained. The amount of usage that it has. Even with Docker being sort of recommended, it's still. Used quite a bit. I'm glad that people found a lot of use out of it.

Jannis: Yeah. How does the move to Docker make you feel? Is that kind of like a bit of a sour side as well, or are you all in for that?

Austin: It's bittersweet in the sense that building Ghost CLI and then having to kill it, there's that aspect of things. But having worked with Docker fairly extensively at the last couple of jobs I've had, it's the right decision, especially with a lot of the additional complexities of ActivityPub and analytics and stuff like that. Ghost CLI just doesn't work anymore for the common hosting model. And there are tons of hosting platforms these days which let you host Docker. It's a little more complicated to do VPS and managing all that. So ultimately it's the right call.

Jannis: Yeah. For a self-host specifically, it takes the complexity away from, I need to get an entire server to, I need somewhere where I can host Docker. And there are, as you said, so many places that let you just do that. So yeah, I'm also excited to see where that goes. Magic pages has always been on Docker, but in the very early days we built our Docker image with the Ghost CLI inside. The official Docker image still does that,

Austin: At least the current v6 version. There's a next variant that removes that. But yeah, that's how it worked in the Docker image for a while.

Jannis: Yeah. And that's the cool thing about software usually. Someone I know always says software is soft and that's kind of those little steps to get to a point where you evolve further and you see what's out there as well. So how does it now work on the other side? You now work within the Ghost Foundation. How does that compare to working as an open source contributor for Ghost or for the project of Ghost?

Austin: It does make me a lot more aware of some of the considerations that aren't necessarily public just because some of it can't be. There's various infrastructure hosting considerations with Ghost Pro, some of which because I'd worked on one of the team weeks 10 years ago on some of the Ghost Pro hosting code just because I was there. And so some of it was still familiar, but a lot of things that it does that sort of inform how Ghost has to be built. And a lot of those do make sense to transfer to self-hosting as well.

But at the same time, it means that certain things which might seem like they're easy to implement in theory become a lot more difficult when you scale. Ghost Pro has, we're in the tens of thousands of sites hosted there and an increase of say 20 megabytes of memory usage times 10, 20,000 sites is a lot.

Jannis: I can attest to that. Just hosting 1,500 sites, an increase in 10 to 20 megabytes is definitely.

Austin: Something you feel as an- Especially these days with memory prices being what they are. Yeah, it's fairly significant. And it's one of those things where looking at the forum and the ideas is, oh yeah, all of these are great. And these are not things that we don't want to do. It's more just how do we prioritize them, especially with such a small team. And it's not all engineers at Ghost. We have our support team and we have the folks that build all the design. There's a fair amount of people who do things that aren't actively working on the Ghost code base. And so it's a huge question of prioritization.

Jannis: Can you give us a little bit of an insight how that happens? So let's say there's an idea in the Ghost forum that somebody posts and what does it take for somebody to pick that up at the Ghost Foundation and say, hey, we want to build that. Is there a decision-making process or in engineering at the Ghost Foundation, how do you decide how those things get together?

Austin: I think it probably differs per team, but I think in a large part, we have to factor it in the case of is this going to be a useful feature for 90% of people? And the percentage may vary slightly, but it's a question of does this make sense to be added to Ghost Core? Are there ways that if we add this, it increases the maintainability burden? WordPress has this extensibility contract that's fairly expansive, but it means that it is a lot harder to make changes going forward without breaking things. And so, especially for things like replacing or making it possible to replace the mail provider for something other than Mailgun, there's a fair amount of considerations there, especially when it comes to things like analytics where Mailgun lets you do polling of their events API, but not a whole lot of other mail providers do that.

And so Ghost's integration right now is built on that polling. There are web hooks that most support, but Ghost's hosting considerations mean that web hooks get a lot more complicated, especially for some of our bigger sites that have hundreds of thousands of members. That's a significant amount of traffic just from web hooks that we have to figure out how to handle. And so it's one of those that seems simple in theory, but then when you start to dig into the side effects of that change, it gets a lot more complicated. And I think oftentimes we draw from the ideas board, but a lot of these are things that we've also considered internally and are planning to do at some point.

But yeah, it all. Depends on what other things are going on. And I think the other thing that affects a lot of this is Ghost's code base was written for a very early version of Node. And the way you would write a Node.js code base in 2026 is very different than you would write one in 2014. And to some extent, we're just paying that cost. There's a lot of stuff in Ghost that made sense at the time, but in retrospect is now technical debt that we have to address. And some of these ideas it's like, okay, great. It would be nice to be able to do this, but in order to make that feasible, we have to go and address a lot of these underlying concerns so that it's easier to add and maintain these new sorts of features going forward. And that's probably the biggest blocker to a lot of these these days.

Jannis: Do you have a rough idea how much time you spend on technical debt versus let's say working on new features in that sense?

Austin: It depends because the cost of the technical debt is probably spread fairly evenly across the different teams. I think it's probably less these days now that we've started to establish a roadmap for refactoring and replacing some of the more antiquated parts of the code base with more modern alternatives. And so determining what is technical debt versus features also gets a little tricky because there might be a case where solving some of that technical debt sort of adds the ability to implement this feature or does implement this feature just by the nature of doing it. But.

I mean, it's probably a bit skewed in terms of technical debt. Like right now, Steve, my counterpart on the platform team is working on removing Ember.js from our admin code base because we've been stuck on a five plus year old version of Ember and that dramatically affects what we can build on the admin side. So yeah, it differs per team, but I think we're hopefully getting to a point where that ratio starts to switch from more tech debt focused and more into building new features that are useful.

Jannis: I mean, we're now already fairly deep into your work at Ghost, at the Ghost Foundation. You also mentioned Steve now. Are you two now basically the two platform engineers that the Ghost Foundation has?

Austin: Yeah. Yeah. We essentially make up the platform team. Hannah is working with us pretty heavily as well, but day to day, yeah, we're the two folks. And we kind of have segmented roles. We work together, but Steve's focus primarily is the contributor lifecycle. So can somebody clone the Ghost repo, make a change, make a PR and have that make sense? And then I'm the second stage of that, which is once a PR is merged, owning the lifecycle of that to a publishable, buildable, deployable Docker image or other aspects of things that self-hosters or our own internal hosting can run. And so that's kind of how that fits.

Jannis: So to just give it a spin in my own words, because I think that platform engineering can mean different things at different companies, but would it be fair to describe it in a way that the two of you work on making Ghost work for people that are not necessarily at the Ghost Foundation?

Austin: Yeah. I think that's our platform team's roadmap. And I think this past week we were discussing a lot about the particulars of our roadmap. And I think that's still reinforced. We've also found that internally too, there are folks that aren't working on the Ghost code base regularly, and they run into some of the same problems that external contributors run into. We're working on improving that. And hopefully some of that bleeds into the open source contributors as well.

Jannis: Can you share some of those things that people run into, like that happens internally, but also externally? What's some of the things that are similar there?

Austin: I think the broadest one that we've had a problem for a while is people making a pull request and it just sitting and not getting reviewed or merged or feedback for a long time. And I think some of that is just because we haven't been focusing on it as much as we should, and that's what we're trying to correct. But the other part is especially more with open source contributors where it's like, oh, this is a new feature and we haven't really discussed how that should be implemented. And so trying to figure out how to come back to a large PR, and some of this feeds into AI built PRs, which is a whole other complexity where it's like, oh, this might make sense, but the way that this contributor has gone about implementing it isn't the correct way.

That takes more time to communicate that in a way that's not like, hey, we don't want this. It's more, hey, we need to discuss how. It makes sense to implement this before someone goes off and spends a bunch of time on it. And so it's this unfortunate feedback loop that makes it less likely that somebody will contribute when there's no guarantee that it'll get merged. And so that's definitely something we're working on improving.

Jannis: Yeah. I mean, I can just attest to that from my own experience. So one of the reasons why you're on this podcast as far as. I have put together is because the episode I had with a couple of weeks ago was also shared within the Ghost Foundation, right?

Austin: Yeah.

Jannis: And the one thing that we pointed out in there was that for us, it's sometimes a bit hard to figure out what we can or should contribute to the Ghost core. And what we always see is exactly that, that there is so much noise that has to be dealt with that sometimes things get lost, which. I think is very natural in a big open source project like Ghost. Are there ways for, let's say, new open source contributors that are not more than me who obviously also have a commercial interest in contributing to the Ghost core to make their PRs in a way or to create them in a way that is easily reviewable for you guys?

Austin: I think Steve probably has a better answer on this than I do, working more closely with it. But for things that are like new feature additions, one of the easiest things is maybe opening up an issue beforehand, just because if it's something that is, oh, we're planning on doing it this way or something to that effect, it can be discussed before somebody goes and spends a ton of time. Having contributed to open source before joining this, it can be pretty demoralizing is probably the right term to spend hours on something and then have it go, no, this isn't the right way to do this.

And then kind of just be left going, okay, I'm going to have to spend a bunch more time reworking it. One of the things that we are working on is getting our sort of standards in the code base documented a little bit better. So not just for humans, but for AI coding agents to be able to look at it and say, this is how you do this particular thing, like adding a new service or adding a new dependency. This is the correct way to do that. And so one, we don't have to spend as much time. On the review side thinking about, does this follow the right patterns? And two, just so that it's easier for somebody to build something new without having to worry about the minutia of, am I using semi-colons correctly or some of the things that ultimately don't really matter as long as everybody agrees on the same way to do it.

So yeah, issues are probably the biggest thing. And yeah, other than that, Steve probably has some better ideas and this is something that we're working on improving.

Jannis: Yeah. I can kind of see from a contributor's side, which is putting on my contributor's hat, I can kind of see why people don't start issues, especially in these days where it is so easy to just say, hey, Claude, please do this. But if you come back to the foundation of open source work, it is literally the foundation of how open source projects work, that you raise an issue, a problem, a feature that you want to see and it is discussed. Yeah. So that's, I think, a very valid point.

Austin: Yeah. And it's been difficult too, because like you mentioned with Claude and all of the other AI agents, the type of open source contribution has changed quite a bit. Like back when I first started contributing, it was a genuine, this hasn't fully gone away, but it was a genuine community of everybody sort of working on different pieces of the thing. And these days there's quite a bit less of that and quite a bit more transactional like contributions where somebody is like, hey, there's this one thing that I need. I'm going to go point Claude at it and open this PR. And that's not to say that there isn't a community because the forum is definitely very active.

And like you and Murat and Cathy have been very helpful in that respect, but by and large, there's a lot fewer repeat contributions from a large group of people. And so it changes the interaction a bit.

Jannis: That's fair. I think the issue we sometimes see is that we don't know where to address that sometimes. So if we take the, let's say new feature stuff again, let me just take a very concrete, recent example. I haven't discussed it with Murat, but I'm just going to take it now. He has recently released on Synaps Media scoped API keys, for example, where I don't know the technical implementation. I assume that he just gates them in front of Ghost somewhere and just says, hey, if this API key gets through, then it's only allowed to do that and that. The topic of scoped API keys and everything has been discussed at the Ghost forum as well for like forever.

And he openly said that he has implemented that on the hosting site because he doesn't know whether it's worth it as a PR. And I think this is where it would help contributors to just have a way of understanding what the process is. Issues as you raised already is I think a great point that you've pointed us at as well to just say, hey, like. I have an actual, you know, not just an idea that I just put in a Ghost forum, but I'd say it would be cool to be able to do this and that, but to actually have that discussion somewhere where the code is.

I think what sometimes, at least historically, I think it's getting a lot better now again, like in the last year or so, but historically what has been the issue a little bit for our side. And. I mean, back then you were also, you know, just an open source contributor. The issue was a bit communication to, you know, understand does that actually get heard? Is there like feedback on that? And this is how I think we kind of drifted in a way that feature work is the Ghost foundation and then bug fixes or like smaller things that can be added is like stuff for open source contributors, which we can easily do if we see it.

Austin: Yeah. Yeah. And I think the scoped API keys specifically as an example is one of those where it runs into two different things. One of them is, as I mentioned before, just technical debt where the permissions model in Ghost. Has sat pretty much unchanged, at least since I started working on it, which was funny to come back and start working on the Ghost code base and go, Oh, that code looks familiar.

But so there's a fair amount of work of that, of like making sure that any sort of feature like scoped API keys, isn't just more duct tape on top of a system that isn't built for like API keys. Realistically, the permissions model as it exists today was built for humans. And so we need some way to retrofit that. And I think the other portion of things is that we haven't been very good historically at sharing our roadmap publicly. And that's partially, I think, because historically we would commit to something.

And then if we found something that prevented that from occurring or some urgent thing came up, then we would have to sort of walk that back. And that led to some issues. And I think that's why we've also stopped really communicating specific dates about things, because then you miss those dates inevitably and people get frustrated. But I think we're starting to get to a point now where, especially like platform team things, we can start to share some of the roadmap that we have. When I shared a few weeks ago that we were deprecating Ghost CLI and going to make Ghost Docker the sort of official thing, it's kind of the first step of that. And I imagine once we have the Ghost 7.0 roadmap a little bit more finalized, we'll probably start to share that as well.

So that it's a little easier for folks to see, Oh, there are these things that are in progress. It's not just, Oh, immediately something's available. These are things we're planning to do. And so for stuff like Scoped API Keys, just hold off for a couple of months and then maybe some of the internal stuff will get redone such that it's now much easier to implement on top of it.

Jannis: And I think I've been in or actively active in the Ghost community for nearly four years now. So I still consider myself fairly fresh compared to you, for example. But you also have to attest to the fact that the communication on things like this has improved a lot. And a lot of that goes to you and Steve. Steve has worked within the Ghost Foundation on that a little bit longer now, but since you also joined him, I just feel like we're kind of on a rocket ship and we're just blasting through those things. So I also just want to take the time to thank both of you for that work because it is visible to contributors outside of the Ghost Foundation as well.

Austin: It's good to hear. That's sort of why the platform team was founded to begin with and it's good that it's starting to work. Yeah. And on that note also,

Jannis: Just a big thanks to John as well, to John O'Nolan, the founder and CEO of Ghost, because as far as. I remember, that was one of the direct consequences of feedback that he received from different open source contributors that he said at some point last year, we need something like this.

Austin: Yeah. I mean, especially with all the security, I mean, that was the big thing was security stuff and Docker image and all that, but yeah. Yeah. So, you know, in all open source.

Jannis: Communities that I know, people like to complain a lot, but I also see a lot of movement in the right direction. And I think we need to embrace that a little bit, see how the next couple of months develop, but I think we're on a really good path with where we're heading as a Ghost community.

Austin: Yeah. And I think our true goal for like Ghost 7.0 is to make it a, not necessarily changing things too dramatically, but making it reshifting things towards more extensibility and more ability for open source contributors to build extensions in Ghost and make the whole open source feedback loop a lot better.

Jannis: We already spoke about that a little bit before we started recording, but I can only repeat what I said back then. I'm really excited to see where you are going to take this. So yeah, very excited for Ghost 7. Yeah. You also mentioned before AI contributions and security specifically. I mean, the two of us, we are very much embedded in that. You from a maintainer side, me from the perspective that. I obviously want to make sure that the Ghost versions that we're running on Magic Pages can hold up to security standards, but can you tell people that might not be that involved a little bit about how AI has changed that and how open source projects are affected by that?

Austin: Yeah. I think we've gotten a little bit on top of things, thankfully, but for a long time, it's just like, there's just so many more things that people find, which is good overall, but it's now meaning that. I have to take, like Steve and I both have to take time away from the new things we're going to do to make sure that we fix all of these security issues. And some are more severe than others.

Jannis: So security issues that people find with AI, report with AI?

Austin: Some of them are for sure generated with AI. And some of them are, at least I don't know that I spend too much time trying to figure out if something's AI generated or not. Some are very clearly that way. We got a bunch that were like specific DNS record things with some of the Ghost domains. And they're just like, no, that's something clearly stated in our security policy is something we don't treat as a vulnerability.

So some of them, it's very clearly just even either AI or some automated scan that just found a bunch of stuff. But there are some that are genuine, oh, we got to actually fix this. And that also runs into the tech debt things. Some of the considerations are just it's an old code base. And there are certain things where we have to spend a lot more time fixing it, or at least reworking certain parts of the code base to not run into these sorts of things as frequently.

Because oftentimes a security fix, you'll just patch one thing and then another thing will come up in a similar part of the code base. It's definitely been a lot, but I think we're starting to get on top of things, which is good.

Jannis: At least what I see from other open source projects, from some of the things I do beside Magic Pages as well, there are two main issues with AI in that. And one is I think that everybody now has access to tools that can break software. And that might not even be something expensive like Claude or a Codex subscription or something. But if. I have a GPU in my computer that I use for gaming, I can download an open weights model. And. I have technically a tool in my hands that can break most software by now. And the other thing that I imagine is probably the sheer amount of reports that you get now that will probably just be a bit overwhelming. Yeah.

Austin: Yeah. I think as we've patched some of the common causes of things, it's gotten less, thankfully. But yeah, I can't imagine what, I mean, seeing some of the stuff from the guy that maintains curl, just seeing the amount of stuff that he gets, it's just insane. I'm fortunate that we're not in that realm where it's used so much more and gets so many more eyes on it. But yeah, it's good that most of those have come through the proper security disclosure process. And it's not like we're seeing active exploits, at least not that I've heard.

So at least it does seem like even for people that generate AI reports, it seems like it's coming from a good place, at least. It's like we want to make open source software more secure, whether it's coming from a place of, oh, I want to be credited on this one thing or not, it ultimately is helpful.

Jannis: Absolutely. I think the only exploit that I know was, I don't remember the details, but it was earlier this year where I think it was an SQL injection or something like this, where somebody could gain access to admin API keys.

Austin: There was two, there was the SQL injection one, and there was a cache header, like a preview thing one, and those were both pretty bad. So fortunately, since then we haven't had any huge, like 9.8 plus severity.

Jannis: Yeah. But those were scary. But the scary part I think happened weeks afterwards, whenever you see on the ghost forum, somebody report an issue and then posting like their ghost version number, which was like a very low six version number or five at some point, with an URL to their actual ghost site. That was always the scary parts where I thought, you need to update your ghost site because this is out in public now.

So yeah, this is also I think where publishers or. People running, not just ghost sites, but any software that is hanging somewhere in the internet need to be more aware that we're not living in times like 15, 20 years ago, where an exploit needs actual knowledge to be used. But that, as I said, right now, anybody that has gamed on their computer at some point is technically able to use those without any knowledge. Just to kind of have an outlook on where things are going, you're working as a platform engineer now for three months, you said, right?

Austin: Thereabouts I joined in mid-June, so three or four months roughly.

Jannis: So if we're looking ahead like next year, Ghost 7 at some point, what would need to happen that you say, okay, this was really successful, I'm happy with the stuff we've been doing as a platform team?

Austin: I think building a setup where people can migrate pretty seamlessly from CLI installs to the Docker setup. That's my main focus right now is making sure that's doable because we're not going to support the CLI going forward. And we want to make sure that people aren't just kind of left hanging. We've run into this a lot with local setups where Ghost CLI is the main way to do a simple Ghost local setup for theme development or other different use cases and trying to make sure that still is supported, even if it's slightly more complicated than it was before.

But I think, yeah, there's a number of other things coming with 7.0 that we're really excited about. And I think I'm hoping they'll be received pretty well. I know some of the things people are probably hoping like mail adapters or different payment providers, stuff like that, may not be in 7.0 just from a timing perspective. And a lot of the technical debt that I mentioned, like cleaning up some of the underlying limitations.

But I think the idea is that Ghost 7.0 gets us into a good spot where we can start to make those sorts of changes moving.

Jannis: Forward. Yeah. I love the idea of building the foundation now or improving the foundation because it's already built. And I think the very important thing that we shouldn't forget as a Ghost community as well is what you said before, that things that might've made sense 10, 12 years ago might not make sense right now. And if you came back after so many years and you thought, oh, well, this looks familiar, then that doesn't necessarily mean that it's bad code right now. It just means that lots of standards are still the same, but it also means that lots of things have moved. And that's, I think, always the challenge we face as developers.

I mean, I know it from our code base at Magic Pages as well, our backend and everything. And that's barely four years old now. And I realized that sometimes, well, that might've made sense four years ago with different decisions made. It might not make so much sense now. So how much of the time do we spend on improving that versus working on the fancy glitter stuff that gets people really excited? But in the end, I think the one thing that we can take from your experience as well is that it sometimes takes those improvements that we don't see to enable all of those things and to enable all of those nice glittery, fancy things that we can do in the future then.

Austin: Yeah. And I guess that's also one of the upsides of AI is making some of these more foundational changes, especially that span the whole repo, are significantly easier when you can do them. With AI, either AI doing the changes directly or writing the scripts to programmatically make these changes. It makes it so much easier to update the old code base. And I think the main thing is figuring out specifically what the new setup looks like to move to that. But that's been one of the definite upsides.

Jannis: Yeah, that's true. I have one potentially odd question for you now towards the end. People that don't like Docker, what would you tell them in that case? It came up a bit in the Ghost forum with Ghost 6 where people said, well, I don't want to learn how to do Docker. I want to stay on the Ghost CLI. What would you tell them to convince them to look into Docker and how that works?

Austin: Funnily enough, when we first started working on Ghost CLI, Ghost itself had a similar approach. For the longest time, Ghost Pro used LXC instead of Docker, which had its own drawbacks. But I think also at the time, 10 years ago, Docker was very much not as fleshed out as it is today. And I can see the whole bit of not wanting to learn a new thing. That's totally understandable. I think one of my goals with the new Docker setup is to try and achieve the same Ghost CLI-like experience without having to maintain a separate CLI, but also trying to make it so that you end up using most of the same Docker commands that you would use for any other open source product.

And I think that's also one of the things that is worth mentioning is Docker and just containers in general is where the ecosystem is going. And one of the benefits is. Specifically from a memory usage standpoint, one of the biggest issues with production CLI installs is it has to install all the dependencies and that can take quite a bit of memory, especially with newer package managers. But with Docker, it's just pre-installed and you just end up essentially downloading them all in one place. And we've done a fair amount of work on Docker image, both the official one and the nightly-ish one that Ghost publishes to make sure that the Docker image is as optimized as it can be.

And that's a lot harder to do with the CLI installs where any optimizations you have to do have to be done in the CLI or done post install, which adds a fair amount of overhead and also potentials for breakage. Whereas in Docker, it's a lot easier to just add those optimizations there. I think the other thing too, that is why Docker makes a lot more sense. Having maintained the CLI for a decade, the amount of problems you encounter when your abstraction layer is the operating system is significantly higher than the amount of problems you encounter when node is your abstraction layer. And so one of the problems with the CLI is we can't officially support anything outside of Ubuntu because Linux distros like to put different things in different places and trying to make a system that handles all of that gets incredibly complicated versus Docker where you can basically standardize around a single OS and distribution model.

And then it's the responsibility of the OS to support Docker. And I do think there are ways that we're trying to also improve the user experience so that people don't have to think about Docker as much. One of those, which I've not really done any code changes in Ghost yet for this, but one of the things that Docker makes doable drawing from some of the examples like Home Assistant is one-click admin updates, which has been a thing that I think people, self-hosters specifically, have been wanting for a while. Not so much on hosting platforms because most of the rollouts are automated, but say you're running a single self-hosting instance and you don't want to have to shell into the server to update something, hopefully with this new Docker setup, that'll actually be.

Jannis: Feasible. Yeah, I've never thought about the updates as well because truthfully that is one of the main issues. We touched upon that quickly, also with security vulnerabilities now. The reason why people didn't update Ghost was because they had to log into the server and they had to figure out how did I install Ghost two or three years ago? What did I do back then to do that? And this is I think where self-hosting software is a lot of fun, but it might not make sense for everybody. If you have never touched a Linux server or Linux itself before, it might not make sense to now get the DigitalOcean droplet with the one-click install because it installs it once for you.

You will not have any automatic update. And if that is a possibility, that you have a one-click updater within Ghost itself, then that would open up that road for a lot more people, I think.

Austin: Yeah, there should hopefully be some progress on that in the next couple of weeks, but in theory also working with the extensibility goal of Ghost itself, making that a pluggable adapter too. The Docker Compose setup uses one way of doing it, but if there are platforms that host Ghost that want to be able to do it in a different way, it might make sense for them to implement an adapter to do that as well.

Jannis: You're telling me lots of exciting news here.

Austin: Yeah, you heard it here first, folks.

Jannis: The gears in my head are already spinning. What can you do with this on a platform like Magic Pages? That's really, really cool. Those are the details that you only find out or that you only figure out when you're really immersed in software like this and when you're really working on those issues for a long time and when it's not just this one thing that doesn't work or. I want to have a different email provider, which is also perfectly fair, but sometimes it's those quality of life features that will impact a lot more people, truthfully, because I don't think that in the sense of security of the overall platform of Ghost, the impact of having a new email provider is as big as having a one-click updater.

Austin: Yeah, and it's also interesting that it brings up that different platforms and different users have different ideas of what the most important thing is. We talked about this internally after listening to you and Murat talk, the focus on different payment providers versus the focus on translations versus what we internally think is the most important thing. It's good to have that feedback of what do people value as the most important thing, and some of that may or may not shape how we think about things internally, but it's definitely good to at least have the knowledge that is important to people. And so even if it feels like, on the forum, that we don't always respond or that we don't think or care about these certain things, I think we do.

I think what we're trying to do is make that feedback loop of, oh, I want something done. Here is why we can't do it now, or here's why it's delayed for whatever reason, make that a little more clear so it's not just shouting into a void.

Jannis: I'm excited where that leads us or how it develops over the next couple of months, and I love the fact that you're thinking about those things. Murat and I, we now hear from different people how it was a topic at the team week, for example, and we're both in awe about that. We would have never expected that. I think a big thanks goes to John for that again, to just also be aware of that and to have that on the radar and to talk about that. And to all of you, to the entire team of the Ghost Foundation as well, to listen to that, to think about it, also to counter some of our points because you have a different experience than we do. We have the perspective of open source contributors.

There is the perspective of people using Ghost on Ghost Pro, on Magic Pages, on Synaps Media, self-hosted, wherever, that have different perspectives again. And then there's the perspective that all of you have, which is, again, different. So I think in the end, the big important goal that we should have in mind is to bring those experiences together somehow and to combine them and see what makes sense for the overall ecosystem. Yeah, definitely. Austin, we've talked about most things that I had on my list, but is there anything from your side, any more topics or anything that you would want people to know?

Austin: I think it's basically just restating what I've mentioned is that we are paying attention internally to a lot of this stuff and we are working to improve how we share. What we're working on internally and how that gets publicized with rough timelines on things. Because we do know it's been a problem in the past. From the early days of Ghost, when it was incredibly open and super transparent about everything, to the last few years where it's been a little more closed and now opening it back up again. Yeah, we're working towards it. And from you and Murat and everybody else that runs hosting platforms, it's helpful to have that.

Even from the community too, just continuing to provide feedback in the forums for how we're doing and how we could be improving, hopefully in a nice way. But in general, we're keeping tabs on things and trying to continually improve how we engage with the community. Well, thank you so much for.

Jannis: Reaching out, first of all, for also making time to come onto the podcast here, for sharing your ideas and thoughts or giving us all of those insights into how you work in the platform team, how the Ghost Foundation works a little bit. And yeah, it was absolutely lovely speaking to you about all of this, Austin.

Austin: Yeah. Yeah. Thank you.

Jannis: All right. Bye-bye.

Austin: Bye.