Custom publication icon not displaying in browser tab

Developer help
1

I have a self-hosted Ghost instance running in a docker container on a Raspberry Pi and connected to the internet using a Cloudflare Tunnel (I followed this tutorial).

Everything works great, except when I upload a custom publication icon, it isn’t shown in the browser tab. In Firefox, there is no icon at all, just text, and in Chrome, there is only the default icon.

I noticed in Chrome that the icon’s URL in the head HTML is:

https://192.168.0.100:2368/content/images/2026/05/favicon.ico

I’m not sure if this is how it should be, but if I change the URL to http:// (rather than https://) then the custom icon appears as it should. So, I’m wondering if it’s maybe a problem with Cloudflare.

Either way, I figured I could just replace the default file instead, which works on a locally installed Ghost instance on my laptop. However, I can’t find the same file on the Docker version.

Any ideas on how to fix this, or where to find the default file on Docker would be great! :)

2

Ergh. I just noticed some other image problems.

Some of the images I’ve uploaded display fine. These have paths like:

/content/images/2026/05/Image01.jpg

But, another, which has a path like the following doesn’t display:

http://192.168.0.100:2368/content/images/2026/05/Image02.jpg

Does this seem like a mixed contents issue? This is my first time self-hosting, so I’m struggling a bit to figure out what’s going on…

3

What is your server’s url parameter set to? Post (minus secrets) your config.xxx.json or docker compose file?

4

Thanks Cathy - it’s set to http (the same as the service for my Cloudflare Tunnel), and the local network address of the machine running Ghost. That’s the only way I was able to see my site via it’s domain address (blog.pauljerem.com).

I’ve tried changing the URL in the compose file to https and then changing the tunnel service on Cloudflare to match. But then, when I try to access the site via the domain address I just get Bad Gateway errors (502, I think).

services:

  blog:
    image: ghost:6
    container_name: ghost
    restart: always
    ports:
      - 2368:2368
    expose:
      - 2368
    volumes:
      - ${DOCKER_VOLUME_STORAGE:-/mnt/docker-volumes}/ghost/content:/var/lib/ghost/content
    environment:
      # see https://ghost.org/docs/config/#configuration-options
      security__staffDeviceVerification: false
      database__client: ${DB_CLIENT:-mysql}
      database__connection__host: ${DB_HOST:-database}
      database__connection__user:  ${DB_USER:-ghost}
      database__connection__password: ${DB_USER_PASS:-}
      database__connection__database: ${DB_NAME:-ghost}
      url: http://192.168.0.100:2368
      NODE_ENV: production
      mail__transport: SMTP
      mail__options__host: ${SMTP_HOST:-}
      mail__options__port: ${SMTP_PORT:-587}
      mail__options__auth__user: ${SMTP_USER:-}
      mail__options__auth__pass: ${SMTP_PASS:-}
      mail__from: ${SMTP_MAIL_FROM:-}

  database:
    image: linuxserver/mariadb
    container_name: ghost-db
    restart: unless-stopped    
    environment:
      - PUID=1000
      - PGID=1000
      - MYSQL_ROOT_PASSWORD=${DB_ROOT_PASS:-}
      - TZ=Europe/Berlin
      - MYSQL_DATABASE=${DB_NAME:-ghost}
      - MYSQL_USER=${DB_USER:-ghost}
      - MYSQL_PASSWORD=${DB_USER_PASS:-}
    expose:
      - 3306
    volumes:
      - ${DOCKER_VOLUME_STORAGE:-/mnt/docker-volumes}/ghost/mariadb/config:/config
5

I think the main thing here is the url value in the compose file. Ghost expects that to be the public URL people actually use to access the site, so in your case it should be the public https://... domain rather than http://192.168.0.100:2368.

The Cloudflare Tunnel origin is a separate setting. I’d leave that as HTTP to port 2368 if that’s what Ghost is listening on. Ghost doesn’t need to handle TLS itself just because the public site uses HTTPS.

If the 502 appeared after you also changed the Tunnel origin to HTTPS, I’d switch that part back to HTTP and keep only Ghost’s public url set to HTTPS. It might also be worth checking that the public Host and X-Forwarded-Proto: https are reaching Ghost as expected.

I wouldn’t replace the favicon file itself. Since some of the post images are also ending up with the private 192.168... address, it looks more like the public URL/proxy configuration is the actual issue.