Turn a GitHub Repo Into a Paid Product with GHRM

VBWD’s GHRM plugin sells subscription-gated repo access: deploy tokens and collaborator invites on activation, auto-revoke on cancel, and Actions-synced releases — all driven by subscription events, with the core untouched.

You can sell access to a private repo as a subscription; VBWD’s GHRM plugin wires GitHub access to the subscription lifecycle without the core ever knowing what GitHub is.

The gap between a public repo and a paid product

You have a repository worth paying for: a component library, a set of infrastructure modules, a data pipeline, a trading toolkit. The code is good. The problem is not the code — it’s the plumbing between “someone pays” and “someone gets access to the repo and keeps getting updates.”

Most people solve this by hand. They collect payment through one tool, then manually add the buyer as a GitHub collaborator, then remember (or forget) to remove them when the card stops charging. That works for ten customers. It falls apart at a hundred, and it leaks money the whole way.

GHRM — the GitHub Repo Manager plugin for VBWD — closes that gap. It ties a subscription to real GitHub access, and it opens and closes that access automatically based on billing events.

What GHRM actually does

GHRM is a plugin (shipped as a bundle) for VBWD, a self-hosted, source-available platform built on Python/Flask, PostgreSQL, Redis, and a Vue 3/TypeScript front end, all running under Docker. VBWD’s core is deliberately agnostic: it knows about users, subscriptions, and billing, and nothing about GitHub. All the GitHub-specific logic lives inside the plugin, which extends the platform through its event bus rather than by editing core. If you want the reasoning behind that split, the platform architecture documents it.

Concretely, GHRM lets you:

Define a catalogue of packages — repositories or distributable artifacts — and tie each one to one or more subscription plans.
Grant paying subscribers access to those repositories automatically.
Sync README, CHANGELOG, and releases so the customer-facing catalogue reflects what’s actually shipped.
Present that catalogue as a CMS page on your own site, on your own domain.

You can browse it alongside the other building blocks on the plugins catalogue. GHRM composes with the subscription, billing, and CMS plugins — you assemble a storefront rather than build one.

The subscription-to-access lifecycle

This is the core mechanic, so it’s worth being precise about it.

VBWD’s core emits subscription lifecycle events: a subscription is activated, renewed, cancelled, or expires. The core publishes these to its event bus. GHRM subscribes to them. When money changes state, GitHub access follows.

On subscription.activated, GHRM does two things through the GitHub API: it issues deploy tokens for the packages the plan covers, and it invites the customer as a collaborator on the relevant repositories. The customer accepts the invite and can pull, or wires the deploy token into their CI. No manual step on your side.

On cancellation or expiry, GHRM revokes that access — after a grace period. The grace window matters: you don’t want a failed renewal or a payment-provider hiccup to lock a paying customer out the same minute. Access winds down on a delay, not a knife edge.

The important architectural point: the core never learns what GitHub is. It fires a generic “this subscription is now active” event; the plugin decides that means “invite this person to these repos.” Swap GHRM for a different fulfilment plugin and the core code is untouched. That’s what “agnostic core, gnostic plugins” buys you in practice.

The release and sync side

Access control is half the job. The other half is that customers need to see what they’re paying for and know when it changes.

GHRM can sync repository metadata — README, CHANGELOG, releases — via GitHub Actions. When you cut a release, an Action pushes the relevant metadata back into VBWD, and your catalogue page updates. Customers see the current version and release notes without you copy-pasting into a marketing page.

Because the catalogue renders through the CMS, it’s a normal page on your site: styled, indexable, linkable. It’s not a bare API response or a third-party storefront you don’t control.

A worked example

Say you maintain a private repo of premium Terraform modules and want to sell access at a recurring price.

First, the one-time setup. GHRM needs a GitHub App with a PEM key and access to the organization that owns the repos, plus OAuth configured so customers can link their GitHub identity. This is the part people underestimate; budget an afternoon for it. The setup steps live in the documentation.

Then you model the offer:

Plan:      "Modules Pro" — monthly subscription
Package:   github.com/your-org/terraform-modules-pro
Catalogue: README + CHANGELOG synced from the repo
Grant:     collaborator invite + deploy token on activation
Revoke:    on cancel/expiry, after the grace window

Now the runtime flow. A visitor lands on your CMS catalogue page, sees the module set with its current release notes, and subscribes. Billing processes the payment and the subscription activates. The core emits subscription.activated. GHRM catches it, calls the GitHub API, and the customer gets a collaborator invite plus a deploy token they can drop into their pipeline:

subscription.activated
   → GHRM: create deploy token for terraform-modules-pro
   → GHRM: invite customer as collaborator (GitHub API)
   → customer pulls / wires token into CI

subscription.cancelled
   → grace period elapses
   → GHRM: revoke collaborator + deploy token

Three months later the customer cancels. The subscription expires, the grace window passes, and GHRM removes the collaborator and revokes the token. You never touched the GitHub settings page. Pricing and plan structure sit under the billing configuration, so you decide monthly versus annual, tiers, and which packages each tier unlocks.

Honest limits

GHRM automates the workflow; it does not rewrite how GitHub works, and a few constraints follow from that.

You’re bound by GitHub’s collaborator model and its API rate limits. If you’re onboarding hundreds of customers in a burst, you’re issuing API calls against those limits, and the collaborator model is GitHub’s, not yours — you inherit its invite-acceptance step and its per-repo access semantics.

Revocation is deliberately delayed. The grace window protects paying customers from transient billing failures, but it also means access does not vanish the instant a subscription lapses. That’s a policy choice you can tune, not a bug.

Most importantly: this gates access, not possession. If a customer cloned the repo while subscribed, revoking their collaborator status does not delete their local copy. What you’re selling — and what GHRM controls — is ongoing access and the stream of updates: new releases, new commits, continued pull access. That’s the honest shape of the product. Source-available and self-hosted software is sold on continuity and trust, not on the fantasy that bytes can be un-shipped.

One more note on VBWD itself: the platform is source-available under BSL 1.1. It’s free to use commercially until your VBWD-attributable annual sales cross a defined threshold, at which point a commercial license applies; the license converts to Apache-2.0 on its change date. You self-host it, so your customer data and your GitHub credentials stay on your infrastructure.

Takeaway

The manual version of selling repo access — take payment here, add a collaborator there, remember to revoke later — is where recurring revenue quietly leaks. GHRM turns that into an event-driven flow: a subscription activates, GitHub access opens; it lapses, access closes after a grace window; a release ships, the catalogue updates. The core stays agnostic, the GitHub logic stays in the plugin, and the whole thing runs on infrastructure you control. If you already have a repo people would pay for, the remaining work is configuration, not code.