--- title: "RepoAccess: sell private GitHub repo access from your own worker" description: "Sell access to a private GitHub repo on your own infrastructure, with the payment provider you already use. Open-source core, one Cloudflare Worker, no per-sale cut." canonical: "https://edgekits.dev/en/tools/repoaccess/" --- # RepoAccess **Sell access to a private GitHub repo on your own infrastructure, with the payment provider you already use.** A buyer pays and is invited to the GitHub team that carries your private repo. A refund or a chargeback takes that access away again. No collaborator to add by hand after every sale, no list to reconcile after every refund. It runs as a single Cloudflare Worker on the free tier: no server, no SaaS subscription, no per-sale or chargeback cut, and no "Login with GitHub" in front of a buyer who has just paid you. GitHub's own invitation is the identity check. ## What your buyer actually goes through Three steps, from the point of view of the person buying from you. ### They pay where you already sell Checkout stays with your provider. You are not moving your storefront, your prices or your payout account to make this work. ### They name their GitHub account Where the provider supports a custom field, they type their username at checkout and are granted straight away. Where it does not, they get a one-time claim link and confirm the handle there before anything happens. ### They are invited to the repo An invitation to the GitHub team holding your private repo, accepted from their email. If the payment is later refunded or charged back, the access goes with it, whether or not you were watching. ## Two ways to run it Pick the one that matches how you already take money. Everything below the two cards applies to both. ### RepoAccess Core Free and open source under AGPL-3.0: the Stripe adapter, the full grant and revoke chain, and the claim page, self-hosted on your own Cloudflare account. ### RepoAccess Pro Every other provider, the Merchant of Record options, the Telegram bot storefront, the worker-hosted Paddle checkout, and support while the providers keep moving. Both are the same engine. The split is which one fits how you already sell. ### A setup wizard your coding agent runs for you Run /repoaccess-setup in Claude Code, OpenCode or any coding agent (the repo carries an AGENTS.md for the ones that need telling) and the wizard walks you to a deployed worker one verified step at a time: your GitHub org and the team settings that keep your repos private, your provider's product and webhook, the secrets, the deploy, and a live end-to-end test purchase at the end. **Your coding agent sets this up without ever seeing your secrets** The rules that enforce that are committed in the repo, so you can check them before you start. The wizard is a program rather than a set of instructions the agent improvises from: the agent runs one command, renders what the program prints, and hands your answer back, while every file that holds a secret is written inside a child process it never reads. The agent's reads of those files are denied by name, and a committed test plants fake secrets and asserts they never reach the agent. Budget about an hour from absolute scratch, counting the Cloudflare account, the GitHub org and the throwaway account that plays your test buyer. Much less when those already exist. The wizard is a convenience and not a requirement: a written guide walks the same road by hand. ## The core is free, and it is the whole engine RepoAccess Core is published on npm as repoaccess-core under AGPL-3.0. It is not a trial or a cut-down build. It is the grant and revoke engine I run in production, with the Stripe adapter included. - Self-host a single Cloudflare Worker, Stripe adapter included. - The full grant and revoke chain: a payment grants access, a refund or chargeback removes it. - The claim page, for providers that cannot carry a custom field at checkout. - Configuration as typed code: one config object your editor checks, not escaped JSON crammed into environment variables. If you sell through Stripe, are happy to maintain it yourself, and want to read every line before you trust it with your buyers, take Core and stop here. ## Which one do you need? The split is about which one fits how you already sell. Pro is not the real product with Core as the teaser. ### RepoAccess Core, free and open source (AGPL-3.0) - Stripe adapter included. - The full grant and revoke engine, and the claim page. - Self-hosted on your own Cloudflare account. ### RepoAccess Pro - Every other payment provider: Paddle, Lemon Squeezy, Gumroad, Razorpay and Telegram Stars, with Core's Stripe adapter still in the box. - Merchant of Record options (Paddle, Lemon Squeezy) if you would rather not own sales tax and compliance. - Customizable claim-page templates. - Provider changes tracked and patched, and a responsible party when something breaks. Stripe + maintain it yourself → Core. Any other provider, or Merchant of Record, or you want it maintained with support → Pro. ## What you are paying for in Pro ### The provider you already use, including the ones that handle tax Stripe is free in Core. Pro is how you sell GitHub repo access with Paddle, Lemon Squeezy, Gumroad, Razorpay or Telegram Stars, including the Merchant of Record options that take sales tax and compliance off your desk. If Stripe does not reach your country, this is the part that matters. ### The Telegram bot is a storefront, not an adapter It lists your products, asks the buyer for their GitHub handle and checks the account exists before it charges anybody, issues the Stars invoice, and grants access on payment. You get a refund button only you can see in your own chat, sales and Stars-balance statistics, and a two-way support relay that carries a buyer's message to you and your reply back to them. Your personal account never appears to the buyer. ### A Paddle checkout page your own worker serves Sell through a Merchant of Record without owning a website at all. That page exists because Paddle needs an approved domain before it will take your money, and its own hosted checkout has no field a buyer can type a GitHub handle into. Your worker answers both problems on your own domain. ### Somebody else tracks the provider changes Payment providers change their APIs and their webhook payloads on their own schedule, not yours. Paddle reports a full refund as partial. Lemon Squeezy emits dispute events it does not document. Razorpay serializes an empty field as an array where its docs promise an object. Stripe rotates signing secrets and sends two at once. Every one of those was found with real money on the line, and Pro is where the next one gets patched before a buyer tells you they paid and got nothing. ### The expensive testing is already done Verifying a pay-to-access flow against a real provider takes days: webhook signatures, refund and dispute events, and the GitHub grant and revoke chain behind them. The live test is the time-sink, not the code. Each adapter ships verified against live providers plus a synthetic end-to-end check, so those days are not yours to spend. ### An embeddable service, documented until an agent can build it Another Worker on your own Cloudflare account calls grant, revoke and claim directly over a service binding: no public URL, no signature, no HTTP hop, because the binding itself is the authorization. The RPC guide is written to be handed to your coding agent, which wires it into your site for you. The proof is the page you are on. Everything a buyer gets after paying here, the handle check, the claim form and the status they watch while access is granted, runs over exactly that binding, and that integration was built from the guide by a coding agent. ## Your brand on every page the buyer sees The worker renders the whole post-payment chain itself: the claim page where the buyer types their handle, the setting-up page while the grant runs, access granted, the failure page, your legal pages, and the Paddle checkout. None of it is somebody else's screen with somebody else's logo on it. Pro ships a registry of designed presets. Each one carries a light and a dark palette, contrast-checked to WCAG AA, and is built on system font stacks, so those pages load no webfont and appear instantly anywhere. You pick a preset in a single file and override any token you like. It follows the buyer's browser by default, and one config value pins it to light or dark if you would rather decide. A selection of the shipped presets, in light and dark. Screens shown: the claim page and the granted page. ## How you get it, and what happens after Pro is delivered by RepoAccess. I sell it the way you are about to. ### Self-hosted on your Cloudflare account I ship the code and you deploy it. Nobody pushes to your infrastructure, and there is no service of mine sitting between your buyer and their invitation. ### Delivered as private repo access You pay, you are invited to the Pro repo, you clone it, add your config and secrets, and deploy. The delivery you are buying is the delivery you receive. ### One-time payment, twelve months of updates and support Applying an update is a git pull and a redeploy on your own account. Your config and your secrets are yours and are never touched. Most updates are provider fixes you would otherwise have chased yourself. ### Let it lapse and nothing breaks If you do not renew, the version you have keeps working. Your clone and your deployed worker are untouched, and your product does not go down because a renewal did. You stop receiving new updates until you renew, and renewing resumes them. ## You are not left alone with the code What ships beside the code, because the code is the easy half. ### One setup guide per provider All six of them. Each one walks its provider's dashboard click by click, in the order that causes the least back-and-forth, and ends with a live test purchase you make yourself. ### Reference notes on what each provider actually does What it signs, byte for byte. Which of its events mean paid, refunded and charged back. The field that survives from the order through to the refund. And where the provider's own documentation is wrong. They exist because every one of these providers surprised me at least once, and most of those surprises only appear when real money moves. Each note records the date it was last checked. ### The RPC guide, if you want your own site to drive it The binding, the six methods it exposes, two end-to-end flows written out, and the claim page you host yourself. It is provider-independent: the RPC surface does not know which payment provider took the money, so it reads the same whichever one you sell through. ### Making the buyer's pages yours The preset registry, the tokens each preset derives, how far an override reaches before you are writing CSS of your own, and where your logo and favicon go. ### Adding a provider I have never heard of If yours is an obscure regional processor, or your company's own internal billing system, AGENTS.md is the recipe: the contract an adapter has to satisfy, three worked examples, and the per-provider notes behind them. It is written so that a coding agent can follow it unaided. The setup wizard has its own document explaining exactly what it does on your behalf, and every release lands in a CHANGELOG that says whether the update touches anything you set. ## Frequently Asked Questions **Q: How do you know the buyer's GitHub username is really theirs?** **A:** Every invitation is paid for. An invite cannot exist without a completed purchase, so there is nothing to farm and nobody to defend against. What is left is a buyer mistyping their own handle, once, at their own cost, which makes this a question about input accuracy rather than access control. One account, one purchase, and you can revoke it. The default claim mode has the buyer type the handle on your own page and confirm it before anything is granted. --- **Q: What happens on a refund or a chargeback?** **A:** Access is revoked automatically. Grant and revoke is the engine's entire job, so there is no list for you to keep in step with your payment provider and nothing to remember on the day a dispute lands. --- **Q: Do buyers have to log in with GitHub?** **A:** No. Delivery is a GitHub team invitation sent to the handle they give you, and they accept it from their email. There is no OAuth app for you to run, and no authorisation prompt in front of somebody who has just paid you. --- **Q: What happens after twelve months?** **A:** About a week before your twelve months end you can renew to keep updates and support running. If you do not, the version you have keeps working, your clone and your deployed worker are untouched, and you simply stop receiving new updates until you renew. Renewing costs a fraction of what you paid the first time: it is a maintenance fee, not a second purchase. --- **Q: Can't I just build this myself in an evening?** **A:** Yes, and for one provider you probably can. A single webhook adapter against Stripe is an evening of work, which is exactly why Core is free and open source: nobody should pay me for that evening. What Pro sells is what the evening does not buy. The edge cases verified against live providers, refunds, disputes, replayed webhooks and signature changes. Every provider beyond Stripe, including the Merchant of Record options. And somebody tracking provider changes for twelve months so the first sign of one is not a buyer who paid and got nothing. The evening is cheap. Keeping it working for a year is the part that costs, and buying that is cheaper than maintaining it. --- **Q: What exactly does a refund take away?** **A:** The product that was refunded, not the buyer. The worker removes them from the teams mapped to that product and cancels any invitation still in flight, then reconciles their organisation membership against live GitHub state rather than against its own records. So a buyer who owns A, buys B and refunds B loses B and keeps A. One thing worth knowing before your inbox finds out: a buyer left in no team at all also gets GitHub's organisation-removal email, which reads like a ban and is not one. A buyer who still holds another purchase stays in that purchase's team and never receives it. --- **Q: What does it cost to run?** **A:** A one-time payment for the licence and no cut of any sale. The only running cost is Cloudflare's, and it is spent at the moment somebody pays you. On the free plan that works out at roughly 600 sales a day when the handle arrives with the payment, or 250 a day when the buyer enters it on a claim page. Past that, the Workers Paid plan is $5 a month and carries tens of thousands of sales a month before usage adds anything to it. You pay Cloudflare, never me. --- **Q: What if I buy it and it does not work out?** **A:** Write to me at hello@edgekits.dev within 7 days of your purchase with a short reason, and I will look at it case by case. A refund can be declined where access has already been granted and extensively used, or where the request is abusive or fraudulent. Worth saying out loud: a refund also revokes the repo access automatically, because enforcing refunds is literally what this product does. You are not being asked to trust a promise I would otherwise have to keep by hand. ## Get RepoAccess Pro **$129** One-time payment, twelve months of updates and support, self-hosted on your own Cloudflare account. ### What you need before you buy So nothing surprises you after paying. - A Cloudflare account. The free plan is enough to start. - A GitHub organization that owns the repos you sell. Personal accounts have no teams, so an org is required, and a free one is fine. - Node and git on your machine. - An account with at least one supported payment provider. [Buy RepoAccess Pro](https://edgekits.dev/en/checkout/repoaccess-pro/) You can also pay with Telegram Stars. Price excludes tax where applicable. Refunds are handled by me personally, case by case, within 7 days of purchase. [Read the refund policy](https://edgekits.dev/en/legal/refund-policy/) Questions before you buy? Write to me at hello@edgekits.dev