PayGlue is a hosted service, and most people should use it that way. This article is for the other group: you want the thing on your own server, in your own account, where nobody can change the terms on you.
That is allowed, the source is public, and there is a compose file that brings the whole stack up. There is also one line in the licence you should read before you start, and a realistic account of what running it costs you in attention rather than money. For why this option exists at all, the group of Ghost publishers with no working payment route is the part of the market it was built for.
What it is, precisely
The code lives at PayGlue/PayGlue-OS under the Business Source License 1.1.
That licence is worth two minutes of your time, because the honest summary is not “open source”. The licence text says so itself, in its own notice section. What it grants is broad, and what it withholds is narrow:
Each released version converts to Apache 2.0 four years after it first became publicly available. So the restriction has an expiry date rather than being permanent, which is the part of BSL that people usually miss.
For a publisher running one site or twenty, none of the restriction applies to you. It is aimed at exactly one behaviour, and it is not yours.
What runs
Four moving parts, and none of them are exotic.
| Part | What it does |
|---|---|
| Python application | Receives webhooks, resolves them, writes to Ghost |
| Postgres | Connections, product rules, the event log |
| Redis | The queue between receiving an event and acting on it |
| Worker | Does the acting, so a slow Ghost never blocks a webhook |
The queue matters more than it looks. A payment provider expects a fast answer when it delivers a webhook, and your Ghost site is a separate machine that might be slow or briefly down. Accepting the event, storing it and processing it separately is what turns a bad minute into a retry rather than a lost sale.
There is a docker-compose.yml at the root of the repository that starts all four together.
The part that used to be a wall
Until recently, starting your own copy meant creating an account with a hosted identity provider first, because the application had no other way to sign anybody in. That is a strange first step for software you were about to run on your own machine, and it was the single most common reason people gave up on the first evening.
An installation can now keep its accounts in its own database. A setup wizard walks you through the first account and your first publication, and you never touch a third-party service to log into your own tool. If you prefer the hosted identity route, that still works too.
What you are taking on
This is where most self-hosting articles stop being useful, so here is the plain version.
Webhooks need a public address with a valid certificate. Payment providers will not deliver to your laptop. You need a domain, a reverse proxy and a certificate that renews itself. If you already run something on a server, this is an evening. If you do not, this is the actual project.
Secrets need somewhere to live. Provider API keys and your Ghost Admin key are stored encrypted, which means there is an encryption key, and losing it means losing access to every stored credential. That key needs to be somewhere other than the server it protects.
The database is the product. Your product rules and your event history are in Postgres. A backup you have never restored is not a backup, and the moment you find out is always the wrong one.
Upgrades are yours. New provider support, security fixes and schema changes arrive as commits, not as something that happens overnight while you sleep.
What it does not save you
Money, mostly, at least at the start. A managed Postgres, a small server and a domain add up to a monthly number that is not far from a subscription, and that ignores your own time.
The reasons that hold up are different ones. You want the data in a jurisdiction you picked. You have a compliance requirement that makes a third-party processor awkward. You want to read what happens to your members’ email addresses rather than trust a description of it. Or you simply want the option, so that a pricing change somewhere else is not your problem.
Those are good reasons. “It will be cheaper” usually is not.
It is the same product
Worth saying plainly: the self-hosted version is not a stripped demonstration of a paid one. It is the same application, with the same provider adapters, the same paywall, the same buy buttons and the same pricing table.
What differs is what surrounds it. The hosted version has the operational side already solved, which is the part you are choosing to take over.
