Best way to host multiple ghost blogs?

Developer help
1

Hi guys, I host a blog on Digital Ocean as well as another one myself on my home server pc. I am running Ubuntu Server 18.04 on the home server with the current ghost install set up with docker. The Let’s Encrypt container is used as a reverse proxy to direct the root domain to the localhost and the port number for this ghost instance.

Now, if I was to run more than one ghost blog on the same server, would it be better to run them as seperate ghost containers or should I natively install and run ghost on the server outside of docker? And then just use ghost-cli to install the multiple ghost blogs in /var/www, /var/www2, /var/www3 etc?

What would be the best practice? At the moment, I am unsure how I would go about backing up the ghost blog running in docker, except that I mapped a volume for the /var/lib/ghost/content to a local volume.

What would you do? And which would be easier to backup and manage?

2

That’s the officially supported route so you might find it’s easier to get help if something goes wrong.

1 Like
3

Okay, makes sense. One problem I already had was the docker does not update as fast.

4

I’m replying 5 years later as this is still a top SEO’d page for this question.

I’ve run multiple blogs both using the Ghost CLI and using containers, so I can speak to the trade-offs.

As @Kevin said, right now the Ghost CLI route is the officially supported method. But it has some drawbacks.

First, this is requires downloading another copy of Ghost for each install you want to upgrade, so upgrading several blogs can feel tedious.

The Ghost CLI tool provides a pleasant, interactive experience and has some built in checks for common problems and can provide you some interactive feedback about what’s wrong.

At the same time, the Ghost CLI has some drawbacks. Because it uses a system node and not a bundled node, some people run into node version mismatch problems. For example, they just assume they can upgrade to the latest version of Node without checking if Ghost supports it yet. Or they upgrade Node to support some non-Ghost project, or they upgrade their OS and end up with a different version of Node. Whatever the reason, they end up a state where Ghost won’t start because the Node version is wrong.

Running Ghost in a container solves multiple problems:

  1. It bundles the correction of Node needed by each version of Ghost
  2. Only one copy of each Ghost version needs to be downloaded for multiple blogs. Unique containers will be created based on the single image for a version.
  3. No more conflicts between the version of Node needed by Ghost and other projects on your system.

While the container install method may be considered more advanced, it’s a common pattern in in 2024 for self-hosting projects. If plan to self-host more besides Ghost, there’s a good chance other projects expect you to know how to host containers so you may need to figure out anywhere. It can be done with the CLI or with GUI apps like Proxmox or Fedora’s Cockpit with it’s Podman support.

Running Ghost in a container also adds some challenges:

  • The container will not handle setting up a reverse proxy
  • The container will not set up a secure certificate.
  • You’ll need to make sure the container starts at boot.

While I use a DIY method myself, there are now projects which help with the details of running containers like Traefik, which will take care of the three points above for you. Traefik Proxy Documentation - Traefik Another option is Portainer, which offers a free community edition for personal use. https://www.portainer.io

While I originally recommended the Ghost CLI method because it seems simpler and is officially supported, in 2024 I recommend hosting as containers, because it solves some problems and odds are if you are hosting Ghost are you are self-hosting things as well, and other projects now commonly use containers as their officially supported hosting method.

Ghost 6 will be the most complex release to date, involving a second service for the first time, an ActivityPub server. That would be an ideal time to start officially using containers to host the project and maybe they will. Choosing to run Ghost in a container now is likely a forward-looking choice.

3 Likes
5

Mark, I’ve been wanting to ask someone, and so I’ll ask you here. It looks like the “official” (which means docker-official, not Ghost-official) images don’t bundle mysql in the container. What are your thoughts on sharing a mysql container vs separate containers for each Ghost install vs just running sqlite3 inside the container. (I know sqlite3 isn’t supported in production, but for some low traffic stuff, I might consider it anyway.)

I’m eye-ing moving some stuff that’s currently on Pikapods and my main site (currently in a VPS that needs to be upgraded) into containers on an 8GB/2cpu VPS, and trying to work through my options. Hostinger is currently running a really good deal on VPS that’s got me tempted. [If anyone wants an affiliate link with an extra 20% off, hit me up.]

1 Like
6

As long your multiple Ghost installs use the same MySQL database version, which is probably the case, I recommending using a single MySQL instance to save memory and have fewer things to manage.

SQLite is not as well supported. Until a fix I made in 5.100, Ghost would crash when upgrading an instance that used SQLite and had more than 500 posts. That’s a sign that not much testing is done with SQLite. Otherwise, SQLite would be fine for serving a small blog.

Your Ghost containers and MySQL container need to be on the same containerized network so that Ghost can access it.

1 Like
7

+1 for Mark’s solution, after having experimented with nearly every imaginable combination of Ghost + MySQL in containerized environments.

2 Likes