How I Self-Hosted Ghost s Fediverse and Took My Own Blog Offline in the Process
There's a correct way to add ActivityPub to Ghost: buy Ghost from Ghost. This is a field report on the other way — six native Ghost blogs on NetBSD, behind Apache and Cloudflare, federated by hand across a hostile NAT, with exactly one self-inflicted 503 along the way.
Or: Buy Ghost From Ghost. Seriously. But If You Insist On Doing It The Hard Way, Here Is The Tutorial, And May Whatever Deity You Self-Host Have Mercy On Your Soul.
Let me save you a Friday afternoon.
If you want ActivityPub on your Ghost blog — a working Network tab, a fediverse handle people can follow, your posts quietly fanning out to Mastodon — there is a correct answer, and it is this: buy Ghost from Ghost. Ghost(Pro). Click a button. Done. It is genuinely good, it federates out of the box, and the money goes to the people writing the software instead of into the void where your weekend used to be.
Still here? Of course you are. You self-host. You read a sentence like "just pay for the managed version" and your skin crawls. Same. So let's do the unsupported thing instead: self-host the ActivityPub service yourself, point your existing, natively-installed, multi-site Ghost herd at it, and discover — together, in real time — every assumption the official tooling quietly makes about your setup.
For context, here is the setup I was working with, a.k.a. the configuration that makes Ghost engineers reach for the whisky:
- Six Ghost blogs, all installed natively with
ghost-cli, running as separate processes on NetBSD. Not the official Docker image. NetBSD. - Fronted by Apache httpd (yes, Apache, on NetBSD, reverse-proxying Node — we contain multitudes), not the nice Caddy config Ghost ships.
- Four blogs terminate TLS locally with Let's Encrypt. The other two sit behind Cloudflare, so their "origin" is plain HTTP on port 80.
- The Ghost servers live in a datacenter at OVH. The only spare Docker host with room for a new service lives... somewhere else entirely, reachable over a VPN.
The official Ghost ActivityPub tooling assumes exactly none of this. It assumes one Ghost, one domain, one Docker network, one shared MySQL, one Caddy. I had six Ghosts, two TLS strategies, three physical locations, and a packet filter with opinions. What could possibly go sideways.
What ActivityPub actually is (the 30-second version)
Ghost 6 ships a separate ActivityPub service. Your web server proxies three magic paths to it:
/.well-known/webfinger → "who is @index@yourblog.com?"
/.well-known/nodeinfo → "what software is this?"
/.ghost/activitypub/* → the actor, inbox, outbox, followers, the works
Everything else still goes to Ghost. Self-hosters get to use Ghost's hosted ActivityPub service for free, or run their own. The hosted path is one line. We are, regrettably, doing the other one.
Step 1: The stack (this part is genuinely easy, savor it)
The production ActivityPub service is delightfully boring. No Redis. No message queue. No Google Pub/Sub emulator (that's a dev-only thing the README will try to scare you with). Just the service, a migrations container, and MySQL:
# compose.yml
name: activitypub
services:
db:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
MYSQL_DATABASE: activitypub
MYSQL_USER: ghost
MYSQL_PASSWORD: ${AP_DB_PASSWORD}
volumes: [ ./data/mysql:/var/lib/mysql ]
activitypub-migrate:
image: ghcr.io/tryghost/activitypub-migrations:1.2.4
environment:
MYSQL_DB: mysql://ghost:${AP_DB_PASSWORD}@tcp(db:3306)/activitypub
restart: "no"
activitypub:
image: ghcr.io/tryghost/activitypub:1.2.4
ports: [ "10.0.0.60:8080:8080" ] # bind to the private IP, not 0.0.0.0
environment:
NODE_ENV: production
MYSQL_HOST: db
MYSQL_USER: ghost
MYSQL_PASSWORD: ${AP_DB_PASSWORD}
MYSQL_DATABASE: activitypub
docker compose up -d. The logs say listening on :8080, message queue disabled, using MySQL as the key-value store. RAM cost: about 100 MB for the service, 450 MB for MySQL. You feel a brief, dangerous sense of competence.
Step 2: Tell Apache about the three magic paths
The Caddy config Ghost ships routes those paths to the service. We translate it to Apache, inside each blog's VirtualHost, after the catch-all <Location /> that proxies to Ghost:
ProxyPreserveHost On
<Location "/.well-known/webfinger">
ProxyPass "http://10.0.0.60:8080/.well-known/webfinger"
ProxyPassReverse "http://10.0.0.60:8080/.well-known/webfinger"
</Location>
<Location "/.well-known/nodeinfo">
ProxyPass "http://10.0.0.60:8080/.well-known/nodeinfo"
ProxyPassReverse "http://10.0.0.60:8080/.well-known/nodeinfo"
</Location>
<Location "/.ghost/activitypub/">
ProxyPass "http://10.0.0.60:8080/.ghost/activitypub/"
ProxyPassReverse "http://10.0.0.60:8080/.ghost/activitypub/"
</Location>
ProxyPreserveHost On is not optional. The ActivityPub service is multi-tenant; it figures out which blog you mean from the Host header. Strip the host and every request becomes an existential crisis.
apachectl configtest && apachectl graceful. You curl your webfinger endpoint, expecting glory, and receive:
{"error":"Forbidden","code":"SITE_MISSING"}
Progress! That 403 is coming from the ActivityPub service, not the old "Ghost adds a trailing slash and 404s" behaviour. The plumbing works. The service simply has no idea your blog exists yet. We'll get to that.
Step 3: The part where the network betrays you
You open the Network tab in Ghost Admin. It spins. The service logs light up with my new favourite error:
ERR No key found for 'pro-it.rocks'
ERR No key found for 'pro-it.rocks'
ERR No key found for 'pro-it.rocks' (×6, because despair scales horizontally)
Here's what's happening. To trust a request from Ghost, the ActivityPub service fetches Ghost's public signing key from https://your-blog.com/ghost/.well-known/jwks.json and verifies the JWT against it. Elegant. No shared database, no secrets to copy around. It just needs to reach that URL.
Can it? Let's ask, from inside the datacenter:
$ curl -s -o /dev/null -w "%{http_code} %{remote_ip}\n" \
https://pro-it.rocks/ghost/.well-known/jwks.json
000
Zero. Zero-zero-zero. The most beautiful HTTP status code, because it isn't one. The container, sitting in the same OVH datacenter as the blog, cannot reach the blog's public IP. This is hairpin NAT — or rather, the lack of it. A box behind a NAT trying to reach the public address of another box behind the same NAT often just... can't. The router looks at you, sees a packet destined for an IP it's translating, and quietly drops it on the floor while making eye contact.
The fix is to stop going out to the internet and back. We tell the container to resolve the blog domains straight to the web server's private IP, with the right SNI so the TLS certificate still validates:
activitypub:
extra_hosts:
- "pro-it.rocks:10.0.0.44" # private IP of the web server
- "netbsd.pl:10.0.0.44"
- "ma.ciejew.ski:10.0.0.44"Recreate the container, curl again from inside:
$ wget -qO- https://pro-it.rocks/ghost/.well-known/jwks.json | head -c 40
{"keys":[{"e":"AQAB","kid":"Kej5Fx18oHe2...
Keys! Actual cryptographic keys! "No key found" vanishes from the logs. We are, against all odds, winning.
(The two Cloudflare blogs don't need this. They resolve to Cloudflare's public IPs, which live on the actual internet rather than in NAT purgatory, so the container reaches their JWKS just fine. The two TLS strategies finally pay a dividend instead of a tax.)
Step 4: The blog still doesn't exist, and that's by design
Webfinger still returns SITE_MISSING. The service knows how to trust your blog now, but there's no row for it in the sites table. Who creates that row?
Not you, with a clever curl. I tried. The registration endpoint —
GET /.ghost/activitypub/v1/site
— is guarded by requireRole(Owner), which means it demands a JWT signed by Ghost's own private key. Not your Admin API key (that's an HMAC key; wrong tool, and also please don't hand your admin key to a federation service). Only Ghost's backend can forge this particular blessing, and it does so when it talks to the service on your behalf.
And here, a connoisseur's detail. Watch what happens when the path has a trailing slash:
/.ghost/activitypub/v1/site → 403 ROLE_MISSING (route matched, auth checked — correct)
/.ghost/activitypub/v1/site/ → 302 (route NOT matched, redirect into the void)
One slash. That's the difference between "your site gets registered" and "your site quietly never registers and you spend forty minutes reading framework source on GitHub at a zoom level usually reserved for eye exams." The good news: route the path cleanly to the service and Ghost calls it slash-free.
So what triggers Ghost to make the call? Restarting the blog. About 75 seconds after ghost restart, the backend wakes up, fetches its own JWKS (now reachable), signs the Owner JWT, calls /v1/site — and the service creates the row:
DBG GET 'pro-it.rocks' '.../v1/site' → 200 (4846ms)
mysql> SELECT host FROM sites;
+----------------+
| pro-it.rocks |
+----------------+
Webfinger flips to 200. The actor resolves with application/activity+json. Your blog is, technically and legally, a person on the internet now. Congratulations, I think.
Step 5: The part where I took production offline (so you don't have to)
Earlier the same day — different task, same blog — I had chown-ed Ghost's content/ directory to a non-root user so I could edit some files without sudo. Felt tidy. Ghost was running, didn't blink. Then, mid-fediverse-dance, I ran ghost restart.
$ ghost start
Message: The content folder is not owned by the current user.
Ensure the content folder has correct permissions and try again.
The blog did not come back. curl returned a crisp 503. ghost-cli refuses to start if content/ isn't owned by the user running Ghost — a check that lies dormant for as long as the process keeps running and detonates the instant you restart. A landmine I had personally, lovingly armed hours earlier.
The fix was thirty seconds (chown -R root:wheel content/ && ghost start) and the lesson is permanent: Ghost's content/ stays owned by root. If you want to hand-edit verification files without root, put them somewhere else entirely and alias them in at the web-server layer. Do not get clever inside content/. It bites on a delay, which is the worst kind of bite.
Did it work?
Yes. All six blogs federate. Each one is followable, posts fan out automatically, and there's a working Notes box if I ever feel like tooting into the timeline. Total moving parts: one Docker host, one multi-tenant service, one MySQL, a fistful of Apache <Location> blocks, four extra_hosts entries to placate the NAT gods, two Cloudflare exceptions, and exactly one self-inflicted outage.
Was it worth it versus clicking "buy" on Ghost(Pro)? Ask me after the next Ghost update, when one of these assumptions shifts under me and the whole webfinger choreography needs re-learning at 11pm. The honest sysadmin's answer is: no, but I learned things, and "I learned things" is the self-hoster's equivalent of "it's not about the money, it's about sending a message."
If you take one thing from this: the supported, hosted version exists, it's good, and the people who built it deserve your money. This entire post is what living without it looks like.
One small favour. If you made it all the way down here — through the hairpin NAT, the trailing slash, the 503 I detonated on myself — you are precisely the kind of person this little experiment was built for. So go ahead and prove the plumbing works: follow @index@pro-it.rocks from your Mastodon (or whatever corner of the fediverse you call home). Paste it into the search box, hit follow, and the next thing I publish will arrive in your timeline through every single one of those moving parts I just spent two thousand words complaining about. It is the most satisfying way imaginable to tell me the webfinger endpoint resolves. Thanks. Now go buy Ghost from Ghost.
Buy Me a Coffee
Fuel my creativity with a coffee — every sip keeps this blog running!
Support This Blog — Because Heroes Deserve Recognition!
Whether it's a one-time tip or a subscription, your support keeps this blog alive and kicking. Thank you for being awesome!
Tip OnceYou read this far.
Subscribe to get the next self-hosting horror story before I take production down again to bring you one — no cloud, no Pro plan, just questionable decisions documented in real time.
Subscribe
