RepoAccess is live: open core, and what the paid tier adds
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.7 days ago Reply
-
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.7 days ago Reply
-
-
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.7 days ago Reply
-
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. Gary7 days ago Reply
-
-
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.8 days ago Reply
-
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.8 days ago Reply
-