Run Your Own PayGlue

A laptop on a bright desk with a code editor open, a second screen behind itPhoto: Christopher Gower
On this page

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.

Where to start

Clone the repository, bring up the compose file, run the setup wizard, connect your Ghost site and one payment provider. Then buy something from yourself in the provider’s sandbox and watch it turn into a member. That last step is not optional, and there is a whole article on why testing before launch is the step people skip.

If you have not yet decided which provider to connect at all, start with the overview of what a non-Stripe provider does on a Ghost site. And if you already sell through Stripe and want to keep it, that combination works too.

GitHub - PayGlue/PayGlue-OS
PayGlue connects Ghost CMS to any payment provider. Source available under the Business Source License 1.1.
GitHubPayGlue

Photo by Christopher Gower on Unsplash

Frequently asked

Can I run PayGlue on my own server?

Yes, including for a publication you charge money for. The licence allows production use and commercial internal use. The one thing it does not allow is offering PayGlue itself to other people as a hosted service.

Is PayGlue open source?

Not in the strict sense. It is under the Business Source License 1.1, which says so plainly in its own text. The source is public, you may read it, change it and run it, and each version turns into Apache 2.0 four years after its release.

Do I need a Supabase account to self-host?

No. An installation can keep accounts in its own database. That was the point of the local identity work: signing up with a hosted identity provider is a strange first step for software you are about to run yourself.

What does it actually need to run?

Postgres, Redis, a Python application and a worker process. There is a docker-compose file in the repository that brings all of it up together.

Will self-hosting save me money?

Probably not at a small scale. A managed Postgres and a small server cost real money every month, and so does the hour you spend when something breaks at an awkward time.