RepoAccess
Sell private GitHub repo access, self-hosted
A 60-second recording of one real run. A buyer types their GitHub username, pays, and is invited to the team that holds the private repo. Then the seller refunds, and the access is gone.
Nobody touches GitHub at either end.
Granting access on payment is the easy half and plenty of tools do it. Revoking it on a refund or a chargeback is where almost everything stops — and that is the half that decides whether you can sell this way at all.
What the refund removes is narrower than it sounds, deliberately. It revokes the product that was refunded, not the buyer: the teams on that grant, plus any invitation still pending, since an unaccepted invite is a grant in flight.
Org membership is then reconciled against live GitHub state — if the buyer is still in a team from another purchase, they keep it and everything it entitles them to.
They leave the organization only when they are in no product team at all. So a buyer who owns A, buys B, then refunds B loses B and keeps A. The check runs against GitHub itself, never against the worker's own records, so it stays correct even after a grant record has aged out.
The video shows the single-product case. The rule above is what happens when you sell more than one thing.
RepoAccess connects a payment to GitHub access. A webhook arrives, the buyer gets an invite to the GitHub team that carries your private repo; a refund or a chargeback removes them again. It runs as a single Cloudflare Worker on your own account, so no service of mine sits between you and your customers.
There is no OAuth anywhere in it. Your buyer never authorizes a GitHub App and never logs in with GitHub to collect what they paid for: they give their username, and they accept the invitation GitHub emails them. That is one less authorization screen between the payment and the product, and one less reason to abandon it. On your side there is no GitHub App to register either.
The core is free and open source on npm under AGPL-3.0, and it is not a trial version: the Stripe adapter, the full grant and revoke chain, the claim page for buyers who mistype their handle, and the setup wizard are all in it. If you sell through Stripe, you never have to pay me anything.
Pro is $129 once. It adds the providers you may need instead of Stripe - Paddle, Lemon Squeezy, Gumroad, Razorpay and Telegram Stars, with the Merchant of Record options among them - plus a Telegram bot that works as a whole storefront, branded pages for everything the buyer sees after paying, a service binding so another Worker of yours can drive it, and one setup guide per provider.
The price includes twelve months of updates and support. After that nothing stops working: your deployed Worker keeps running and your copy of the code stays yours. Renewal is not a second purchase - it is a nominal yearly fee, and only if you want to keep receiving updates, which in practice means provider changes tracked and patched as they happen.
The setup wizard is optional. Run it and your AI coding agent takes the routine off your hands and walks you through every step to a working deployment, which is about an hour with your accounts already in place. Skip it and you fill in the config files yourself, following the written guide that ships for each provider. Early days: zero sales so far.
5 Comments
The refund/revocation logic is the part that seems commercially meaningful. Have sellers actually used RepoAccess for paid private repos yet, and did automated revocation remove a problem that was stopping them from selling this way?
No, not yet — the only seller running it is me. RepoAccess went public a week ago and I have not sold a single paid licence, which is why the revenue on this page says $0 rather than something vaguer.
So I cannot tell you it removed a blocker for anyone else. What I can tell you is where the design came from. I compared about twenty ways to sell access to a private repo, and almost none of them revoke on a refund: you get the invite automated, and then you are back to watching your provider dashboard and removing people by hand. Of everything I looked at, exactly one re-issues an invitation before it expires.
Whether that is a real blocker or just an annoyance people absorb is the thing I genuinely do not know yet, and it is the honest gap in the story. My own reason was narrower — I sell from a country the usual processors do not serve, so I needed the whole chain on infrastructure I control regardless of who else cared.
Are you selling access to anything that way now, or looking into it?
That distinction between a real blocker and an absorbed annoyance is interesting. I’d be interested in digging into that further. If you’re open to it, what’s the best email to reach you on?
gary [at] edgekits [dot] dev, happy to dig into it.
Let me be precise about what I have and what I do not. No data on other sellers using RepoAccess, because there are none yet. What I do have is the survey of what today's tools do about refunds, and one earlier round of solving this myself: back when I sold WordPress plugins I built my own order panel and the matching kill switch inside the plugin, so issuing a refund and ending access were one button. Nobody sold me that. There was nothing to buy.
So my honest position is that I have evidence this is worth building and none that it is worth buying. Those are different claims, and the second one is what I cannot make yet.
If you have watched sellers run into this from the other side, that is exactly the part I am missing.
PS: email address written like that because new accounts here cannot post links yet. It is also in the footer of my site.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.