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.
-
1Perfect thanks Gary. Really appreciate you digging through the full report and moving on the fixes so quickly. The release note is absolutely fine. Ping me when the new version is live and I’ll rerun the full benchmark and then I’ll send you the public writeup before anything goes up.
-
1Joseph, 3.2.0 is live: npm (repoaccess-core@3.2.0) and GitHub (tag v3.2.0). You're credited in the release notes and the changelog, as promised. All three groups from your report are closed: the refund-during-grant race (the claim guard is now the per-transaction ledger, and the refund is recorded there first), the empty-metadata refund that left the guard idle, and the shared-team case - refunding one of several products on the same team now keeps the team until the last entitling purchase is refunded. I've sent you the details that matter for the rerun by email (a couple of things changed that a harness would trip on). Looking forward to the results - and to reading the writeup before it goes up.
-
-
1Absolutely happy to share it Gary. I’ll send the repro and the full report over by email today. Once you’ve got the next sprint out, I’d also be happy to run RepoAccess through Factory again and compare the before/after. If you’re comfortable with it, I’d love to use the benchmark as a public example of the kind of edge cases we’re testing.
-
1Thanks for this, Joseph. I read the whole thing, traces included, and it is careful work. Quick status: the in-flight revocation and the early-refund groups were fixed right after your first comment, with tests that fail on 3.1.0 and pass now, plus a couple of neighbouring cases your run did not reach. The shared-team one is confirmed and is going into the same release, so when you rerun you get a version that answers all three. I will ping you the moment it is public, with the version number. Yes to the before/after rerun, and yes to the public example once the release is out. I would just like to read the draft first, only to check the facts. One small thing: I write the tests myself from your descriptions rather than pulling harness code into the repo. That is the project's contribution policy, nothing to do with your work. The release notes name you as the reporter. Hope that is fine, say if not. Gary
-
-
1Congrats on getting this out Gary! I ran the open-source core in a sandbox. The normal refund flow checked out, and duplicate webhooks were handled cleanly. I found one interesting timing edge case: when a full refund finishes while an access grant is paused the original grant can resume and add the buyer afterward. Should the refund take precedence there? Happy to share the small repro with you.
-
1Thanks for actually running it, and for the precise description. You are right about the shape: the revocation check happens once, at the start of a grant, and a step replayed after a pause or a backoff sleep does not read it again, so a refund that lands in between wins on paper and loses on GitHub. Yes, please share the repro. An issue on the core repo (EdgeKits/repoaccess-core on GitHub) is the best place; a gist or hello@edgekits.dev works too. It will be fixed in core, and I will credit you in the release notes if you want that.
-
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.