Ghost + n8n: Manual Webhook Workflow Setup (and Why It Gets Complicated)
n8n is a powerful open-source automation tool. You can use it to connect payment providers to Ghost – but the setup is more involved than most forum posts suggest. Here is what it actually takes.
n8n is a powerful open-source automation tool. You can use it to connect payment providers to Ghost – but the setup is more involved than most forum posts suggest. Here is what it actually takes.
What n8n is and when it makes sense
n8n is an open-source workflow automation tool. You build visual flows that connect different services. It has nodes for hundreds of APIs and supports custom webhook triggers. For developers who want full control and are comfortable running infrastructure, it is a solid tool.
n8n Cloud exists, but the self-hosted version is what most Ghost forum discussions refer to. Self-hosting means you run n8n on your own server or VPS, and you are responsible for keeping it online, updated, and monitored.
Who this is for: n8n makes sense if you are a developer, already run your own infrastructure, and need automation across many unrelated services. For Ghost membership sync specifically, it is likely overkill.
Self-hosting n8n
To self-host n8n you need a VPS or server with Docker installed. The typical setup uses Docker Compose with n8n, a Postgres or SQLite database, and a reverse proxy (Nginx or Caddy) to expose n8n over HTTPS.
Your webhook URL must be publicly accessible with a valid SSL certificate, otherwise payment providers will refuse to deliver events to it. This alone rules out local development machines and requires a dedicated server.
| Component | Your responsibility |
|---|---|
| VPS / server | Provision, patch, monitor uptime |
| n8n updates | Pull new Docker image, restart, test |
| SSL certificate | Renew, configure reverse proxy |
| Database backups | Schedule, store, verify |
Building the webhook workflow
Once n8n is running, you create a workflow with a Webhook trigger node. This gives you a URL to paste into your payment provider's webhook settings. When an event arrives, the workflow runs.
From there you need to add nodes for: parsing the incoming payload, extracting the customer email and product ID, mapping the product ID to a Ghost tier, and calling the Ghost Admin API with the correct membership update.
Each payment provider sends differently structured payloads. A Polar subscription event looks nothing like a PayPal IPN. You need separate workflow branches for each provider and each event type you want to handle.
Edge cases you have to handle yourself
- Signature verification: n8n does not verify webhook signatures by default. You need to add a code node and implement HMAC verification yourself for each provider.
- Idempotency: Payment providers may send the same event multiple times. Without deduplication logic, a customer could be granted or revoked access twice.
- Retry logic: If the Ghost API call fails, n8n marks the execution as failed. There is no automatic retry. You must either build one or check the execution log manually.
- Cancellation and renewal events: Subscription state changes require different API calls. A cancellation must revoke access. A renewal must extend it. Each path needs its own workflow branch.
Honest verdict
n8n is a great tool for developers who need general-purpose automation. For Ghost membership sync specifically, you are building a bespoke integration from scratch, maintaining infrastructure, and handling edge cases that a purpose-built tool already solves.
If you enjoy building and maintaining this kind of thing, go for it. If you want the webhook sync to just work without thinking about it, PayGlue is the faster path.
Foto von Elmer Cañas auf Unsplash
