RepoAccess

Sell access to a private GitHub repo on your own infrastructure, with the payment provider you already use.

A buyer pays, and they're automatically invited to the GitHub team that carries access to your private repo. A refund or chargeback revokes it. It runs as a single Cloudflare Worker on the free tier: no server, no SaaS subscription, no per-sale cut.

Use it to sell SaaS boilerplates, starter kits, courses, AI notebooks, private modules, or paid community resources. Anything delivered as a repo.

repoaccess-core is the free, open-source (AGPL-3.0) core. It ships the Stripe adapter plus the full grant and revoke engine. RepoAccess Pro (see below) adds more payment providers (including Merchant-of-Record options) for sellers who can't use Stripe, premium claim-page templates, and support.

Why this exists

Tools like Polar, Dodo, and GitHub Sponsors also solve "pay, then GitHub access", but they're billing platforms: you adopt their checkout and they take a per-transaction cut. Two consequences:

• They're Stripe-bound. If you're somewhere Stripe isn't available (much of CIS, MENA, Africa, Asia, and beyond), you're locked out.
• They own the rail. You can't bring the provider you already sell with, and you pay a % forever.

RepoAccess is the opposite: a light, single-purpose access-grant worker you self-host and wire to any webhook-capable provider. Bring your own Stripe, Paddle, Lemon Squeezy, or Gumroad. Keep your checkout, your margins, and your region.

How it works

1. Your provider fires a webhook to your worker on a sale (and on refunds or chargebacks).
2. The worker verifies the signature, normalizes the event, and runs a durable Workflow.
3. The buyer lands in the GitHub team that carries your repo. By default they open a one-time claim link and enter their GitHub username; if your checkout already collected the username, they're added directly.
4. On a refund or chargeback (within a 180-day window), access is revoked and any pending invite is cancelled.

No "Login with GitHub", no phoning home: GitHub's own invitation is the identity check. Only the real account owner can accept it.

Guided setup (recommended)

The fastest way in is the built-in setup wizard. Clone the repo and run it in Claude Code:

git clone https://github.com/EdgeKits/repoaccess-core.git
cd repoaccess-core
npm install
claude            # then type: /repoaccess-setup

/repoaccess-setup hand-walks you through the entire setup, one verified step at a time: your GitHub org and team plus the privacy settings that keep your repos private, the Stripe product and webhook, your secrets, deploy, and a live end-to-end test. It edits the config files for you and guides the dashboard clicks (no digging through docs), and it never sees your secret values.

During the wizard, your coding agent runs setup commands (wrangler, npm) and edits two config files (src/config/repoaccess.config.ts and wrangler.jsonc) for you. It will ask you to approve each step - approve them to continue (you can pick 'yes, and don't ask again' for a repeated command). The agent never reads your secret file (.dev.vars); you paste your secrets there yourself.

Other agents (Codex, OpenCode, Cursor, ...): the wizard is agent-agnostic. Claude Code and OpenCode both expose it as the /repoaccess-setup command; for any other coding agent, open the cloned repo and ask your agent to follow docs/setup-wizard.md - the same shared orchestrator the slash commands run.

Rather wire RepoAccess into an existing worker by hand? Use Compose it yourself below.

Compose it yourself

npm install repoaccess-core hono

hono is a peer dependency (RepoAccess is built on Hono). npm 7+ installs it automatically, but pnpm and Yarn require it listed explicitly, so install it alongside.

Compose the adapters you use and pass a typed config:

// src/index.ts
import { createWorker, createAccessWorkflow, ClaimGuard } from 'repoaccess-core'
import { stripe } from 'repoaccess-core/adapters/stripe'
import { config } from './repoaccess.config'

// Pass the SAME adapter list to both factories.
const adapters = [stripe]

export default createWorker({ adapters, config })
export class AccessWorkflow extends createAccessWorkflow(config, adapters) {}
export { ClaimGuard }

adapters is optional for hmac-only setups (Stripe), but pass it to both so adding an api_callback adapter later just works.

// src/repoaccess.config.ts
import type { RepoAccessConfig } from 'repoaccess-core'

export const config: RepoAccessConfig = {
  githubOrg: 'your-org',
  productTeamMap: {
    stripe: { prod_ABC: { teams: ['pro'], grant_mode: 'username' } },
    defaults: {
      teams: [],
      grant_mode: 'claim',
      revoke_policy: { mode: 'log_only' },
    },
  },
}

Add the Cloudflare bindings (Workflow, KV, Durable Object), put your secrets (GITHUB_TOKEN, STRIPE_WEBHOOK_SECRET) in .dev.vars, and wrangler deploy. Full walkthrough: setup guide.

What's in core

• Stripe adapter: HMAC-verified checkout.session.completed, charge.refunded, charge.dispute.created.
• Grant and revoke engine: a durable Cloudflare Workflow, idempotent on retried webhooks, GitHub rate-limit backoff, and reconciliation around manual changes.
• Claim flow: a one-time claim link plus a single-flight Durable Object so two submissions can't over-grant. The claim page is a pluggable, seller-brandable template.
• Config as code: a typed config object, no escaped-JSON env vars.
• Safe outbound events (optional): signed access.* and claim.* webhooks with an SSRF allowlist.
• Stays on the Workers free tier.

RepoAccess Pro

Core is everything you need to self-host with Stripe. Pro is for sellers who need more:

• More payment providers: Paddle and Lemon Squeezy (Merchant-of-Record, with tax handled for you), Gumroad, Razorpay (India), and Telegram Stars (in-Telegram checkout). Sell from the regions, and with the providers, a Stripe-only setup can't reach. More providers are on the way.
• Premium claim-page templates: polished, branded checkout-to-access pages.
• Priority support and quality-of-life extras.
• One-time license, your own infra, no per-sale cut.

Pro is launching soon. For early access and early-bird pricing, join the Early Birds list at edgekits.dev.

License

AGPL-3.0-or-later. Copyright © 2026 Gary Stupak. See LICENSE.

If you run a modified RepoAccess as a service for others, the AGPL's network-use terms apply (see the FAQ below). For a closed-source or otherwise proprietary use, the licensed edition is RepoAccess Pro - there is no separate commercial license for core.

License and AGPL FAQ

RepoAccess core is licensed under AGPL-3.0. Plain-English answers to the questions people actually ask (this is not legal advice - for edge cases, consult a lawyer):

Can I self-host it to sell access to my own private repos? Yes, freely - that is the intended use. If you run it unmodified, its source is already public (this repo), so you have nothing extra to do. AGPL covers the RepoAccess source itself; it does not require you to open your repositories, your buyers' data, or your business.

What if I modify core and run it as a service? AGPL's network clause (section 13) applies: if you modify RepoAccess and let users interact with your modified version over a network, you must offer those users the complete corresponding source of your version - by providing a public download (a public git repo or archive), prominently, at no charge. That is an accessible offer to the people using your service, not private correspondence. In practice: publish your fork's source and link it from the running service.

Does importing core into my own worker make my whole app AGPL? Combining AGPL code into your worker generally makes the combined work subject to AGPL, so if you offer it over a network you would owe its corresponding source to your users. If you need a closed-source commercial product, that is exactly what RepoAccess Pro is for: a separately, proprietarily licensed edition (including the embeddable RPC service) with no AGPL obligation. Use core (AGPL) for open / self-hosted; use Pro for closed commercial.

Is there a commercial license for core? No - the proprietary path is Pro. Core is AGPL-only by design: the copyleft is what stops someone from privately forking it into a closed, competing service.

(Not legal advice. The "derivative work" vs "mere aggregation" boundary has nuance; consult a professional for your specific situation.)

RepoAccess is part of EdgeKits.