Zugang zu einem privaten GitHub-Repository verkaufen, ohne SaaS dazwischen

Der kostenlose Tarif von Polar nimmt 5 % plus 50 Cent von jedem Verkauf. Verkaufe ein Boilerplate für 149 Dollar hundertmal, und der Zähler steht bei 795 Dollar.

Fairerweise: Diese Gebühr kauft eine ganze Plattform, Checkout, Steuern, Streitfälle. Wenn du aber schon einen Zahlungsanbieter hast, fehlt dir nur ein einziges Stück, die Auslieferung: ein Webhook und eine GitHub-Team-Einladung pro Käufer. Genau diese Lücke habe ich gebaut, und quelloffen veröffentlicht.

Was es wirklich braucht, um Zugang zu einem privaten GitHub-Repository zu verkaufen

Die Aufgabe klingt trivial und ist es nicht. Bei Zahlung wird das GitHub-Konto des Käufers in das Team eingeladen, das das Repository hält. RepoAccess macht das ohne OAuth: Der Käufer tippt seinen GitHub-Benutzernamen ein und nimmt eine E-Mail-Einladung an, also gibt es im teuersten Moment des Funnels keine App zu autorisieren.

Die Kehrseite: Ein Benutzername kann falsch getippt sein, also braucht der Käufer einen Weg zur Korrektur, der kein Support-Thread ist. Bei Rückerstattung oder Rückbuchung wird der Zugang wieder entzogen, nach dem Zeitplan des Anbieters, nicht nach deinem. Und all das muss idempotent laufen, weil Zahlungsanbieter Webhooks wiederholen.

TL;DR

• RepoAccess macht aus Zahlungs-Webhooks GitHub-Team-Einladungen; Rückerstattungen und Rückbuchungen entziehen den Zugang automatisch
• Es läuft als ein einziger Cloudflare Worker im kostenlosen Tarif: kein Server, kein SaaS-Abo, keine Provision pro Verkauf
• Käufer autorisieren nie eine OAuth-App; sie tippen einen GitHub-Benutzernamen ein und nehmen eine E-Mail-Einladung an
• Der AGPL-Core bringt einen vollständigen Stripe-Adapter mit; andere Anbieter docken an einen dokumentierten Vertrag an

Meine eigenen Produkte werden als Zugang zu privaten Repositories ausgeliefert, nicht als Downloads, und diese Auslieferungsschicht war das eine Stück, das ich nicht kaufen konnte, ohne die Plattform von jemand anderem zu übernehmen. Also habe ich sie als einzelnen Cloudflare Worker gebaut, meine eigenen Produkte dahinter gestellt und den Core quelloffen veröffentlicht. Dieser Artikel geht die Architektur durch: was passiert, wenn jemand bezahlt, warum es ein Worker ist und kein Dienst, und wo die schwierigen Stellen tatsächlich lagen.

Der Stack, damit sich der Code unten ohne Raten liest: TypeScript, Hono 4 als Router, Cloudflare Workers als Laufzeit, Cloudflare Workflows für die dauerhaften Schritte von Freigabe und Entzug, und Workers KV für Claim-Tokens und Freigabe-Datensätze. Keine Datenbank, kein Queue-Dienst, kein Framework darüber hinaus. Der Core steht unter AGPL-3.0 und liegt auf npm als repoaccess-core.

Was passiert, wenn jemand bezahlt

Jede Anbieter-Integration endet an derselben Eingangstür: Der Anbieter schickt per POST an /wh/<adapter> auf deinem Worker. Die Route prüft, bevor sie parst. Für Stripe ist das eine timing-sichere HMAC-Prüfung über den byte-genauen rohen Body, denn JSON vor der Prüfung neu zu serialisieren ist die Art, wie Signaturfehler entstehen. Erst danach übersetzt der Adapter die Nutzlast des Anbieters in die eine Form, die die Engine spricht:

export interface NormalizedEvent {
  event_type: 'payment_success' | 'refund' | 'chargeback'
  product_id: string
  /** Stable correlation key - identical across an order and its later refund/chargeback. */
  transaction_id: string
  buyer_email: string | null
  github_username: string | null
  /** Refund events only: true=full, false=partial, null=n/a. */
  is_full_refund: boolean | null
}

Drei Ereignistypen sind das gesamte Vokabular. Alles andere, was ein Anbieter schickt, ist Rauschen, das der Adapter herausfiltert, und transaction_id ist der Korrelationsschlüssel: Die Rückerstattung, die drei Wochen nach der Bestellung eintrifft, trägt dieselbe ID, und so findet der Entzug seine Freigabe.

Das Ereignis wandert dann in einen Cloudflare Workflow, und die Instanz-ID leistet mehr, als es aussieht:

const event = adapter.parse(raw)
if (!event) return c.text('unprocessable entity', 400)

// Deterministic Workflow id = the idempotency key. This IS the dedupe
// mechanism - no KV bookkeeping. A duplicate id is silently skipped.
const id = await workflowInstanceId(
  adapter.name,
  event.event_type,
  event.transaction_id,
  event.is_full_refund,
)
await c.env.ACCESS_WORKFLOW.createBatch([
  { id, params: { adapter: adapter.name, event, origin: 'webhook' } },
])
return c.text('ok', 200)

Anbieter wiederholen Webhooks, manchmal Sekunden später, manchmal nachdem dein Worker längst mit 200 geantwortet hat. Die übliche Lösung ist eine Tabelle gesehener Ereignis-IDs.

Diese Engine führt keine solche Tabelle: Die Instanz-ID wird aus dem Ereignis selbst abgeleitet, also baut eine Wiederholung dieselbe ID, und die Workflows-Laufzeit überspringt das Duplikat. Idempotenz durch Konstruktion, nicht durch Buchführung.

Und is_full_refund steckt aus gutem Grund in der ID: Eine in zwei Etappen gezahlte Rückerstattung muss zwei Instanzen werden, nicht eine still deduplizierte. Mehr dazu im Abschnitt über die schwierigen Stellen.

Im Workflow läuft die dauerhafte Arbeit als wiederholbare Schritte: product_id auf seine GitHub-Teams abbilden, GitHub aufrufen, den Benutzernamen einladen. Eine Rückerstattung oder Rückbuchung schickt das Gegenteil durch dieselbe Pipeline, und der Entzug ist ein Abgleich mit dem echten Zustand bei GitHub statt eines gespeicherten Flags: Eine Mitgliedschaft, die schon weg ist, gilt als weg, und das DELETE ist ein No-op. Diese Eigenschaft macht jede Wiederholung in dieser Engine harmlos.

Trifft eine Zahlung ohne brauchbaren GitHub-Benutzernamen ein, also nichts eingetippt, ein fehlerhafter Handle oder ein Name, den es auf GitHub nicht gibt, dann kippt die Freigabe nicht in einen Support-Thread. Der Worker erzeugt ein Einmal-Token, das an die Transaktion gebunden ist, und der Käufer bringt den Vorgang auf einer Claim-Seite zu Ende, die derselbe Worker ausliefert: Benutzernamen eintippen, bestätigen, Einladung erhalten.

Das Projekt nennt das den Tippfehler-Pfad, und er ist ein Sicherheitsnetz, kein Schritt im Ablauf irgendeines Anbieters. Den einen Fall, den kein System abfangen kann, ist ein Tippfehler, der das echte Konto einer anderen Person trifft; nichts weiter unten kann das von einem korrekten Kauf unterscheiden. Deshalb trägt jedes access.granted-Ereignis sowohl die Transaktion als auch den Handle, und ein Ticket der Sorte “Ich habe bezahlt und nichts bekommen” ist mit einem Blick gelöst.

Warum ein einzelner Cloudflare Worker und keine Plattform

Zurück zum Rechenbeispiel vom Anfang. Der Prozentsatz einer Plattform ist ein fairer Preis für Checkout, Steuerabwicklung und Haftung bei Streitfällen, wenn du das brauchst. Wer schon Stripe hat, oder Paddle, oder irgendeinen Anbieter mit Webhooks, bezahlt seinen Zahlungsdienstleister bereits genau dafür.

Was übrig bleibt, ist die Auslieferung, und die ist klein. Ein Verkauf kostet den Worker einen Webhook-Request, eine Handvoll KV-Operationen und einen Aufruf der GitHub-API.

Das engste Limit des kostenlosen Tarifs, das er berührt, sind die 1.000 Schreibvorgänge pro Tag von KV, und ein Verkauf sind ein paar Schreibvorgänge. Der kostenlose Tarif rechnet Hunderte Verkäufe pro Tag also mit null ab, ohne einen Server, der dazwischen leerläuft.

Der zweite Grund ist Identität. Nirgends im Ablauf gibt es ein “Login with GitHub”: keine OAuth-App zum Registrieren, keine Callback-Route, keinen Session-Speicher, kein zusätzliches Secret, das still ablaufen kann. Der Worker hält überhaupt keine Käuferidentität; er macht aus einem Zahlungsereignis eine Team-Einladung, und das ist die ganze Beziehung.

Der dritte Grund ist Vertrauen, und er zeigt in Richtung Open Source, nicht davon weg. Um Team-Mitgliedschaften zu verwalten, braucht der Worker ein GitHub-Token mit echter Macht über deine Organisation. Ein solches Token würde ich keinem geschlossenen Binary eines Fremden geben, und das erwarte ich auch von dir nicht. Deshalb steht der Core unter AGPL-3.0, und jede Zeile zwischen Webhook und GitHub-Aufruf liegt im Repo.

Die schwierigen 20 %: Signaturen, Rückerstattungen, Idempotenz

Der Happy Path dieses Produkts ist ein Wochenendprojekt, und ich tue nicht so, als wäre er mehr. Was Monate an Live-Läufen brauchte, bis ich ihm traute, ist alles um den Happy Path herum: die Fälle, die entscheiden, ob ein Fremder kostenlos Zugang bekommt oder ein zahlender Käufer seinen verliert.

Prüfe die Bytes, die du bekommen hast, nicht das JSON, das du geparst hast

Die HMAC-Prüfung läuft über exakt die Bytes, die der Anbieter geschickt hat. Parse den Body und serialisiere ihn neu, und die Signatur bricht an der Reihenfolge der Schlüssel, an Leerraum oder an einem Unicode-Escape. Deshalb behält der Worker den rohen Text und prüft, bevor irgendetwas JSON.parse berührt.

Der Signatur-Header von Stripe kann mehrere v1-Signaturen gleichzeitig tragen, so funktionieren Secret-Rotationen, also akzeptiert der Prüfer jede davon, innerhalb eines Replay-Fensters von 300 Sekunden, dem Standard in Stripes eigenen Bibliotheken. Und der Vergleich selbst darf kein Timing verraten:

/**
 * Constant-time hex compare. The length check is acceptable: a digest's
 * length is fixed by its algorithm, so a mismatch only ever means an
 * invalid signature, not a secret-dependent branch.
 */
export function timingSafeEqualHex(a: string, b: string): boolean {
  if (a.length !== b.length) return false
  let diff = 0
  for (let i = 0; i < a.length; i++) diff |= a.charCodeAt(i) ^ b.charCodeAt(i)
  return diff === 0
}

Nichts davon ist exotisch. Alles davon ist genau das, was eine Happy-Path-Integration auslässt, und es hier auszulassen heißt, dass ein gefälschter Webhook Zugang zu deinem Repository freischalten kann.

Die Rückerstattung, die in Etappen kommt

Der beste Bug in der Geschichte dieser Engine wurde gefunden, bevor sie je einen echten Käufer sah. Anbieter können eine Zahlung in Etappen erstatten, und die Engine hat eine Richtlinie full_refund_only: Eine Teilerstattung läuft durch und überspringt den Entzug korrekt.

Die Workflow-ID einer Rückerstattung war früher {adapter}-refund-{txn}. Als ein späteres Ereignis die Rückerstattung vervollständigte, trug es dieselbe Transaktion, baute dieselbe ID, und dieselbe Deduplizierung, die vor Wiederholungen schützt, verschluckte es still. Ein vollständig erstatteter Käufer behielt seinen Zugang, also genau der Fall, für den diese Richtlinie existiert.

Die Lösung steckt in der ID selbst. Die Instanz-ID einer Rückerstattung trägt jetzt ihren Umfang, sodass eine Wiederholung weiterhin dedupliziert wird, gleiche Antwort, gleiche ID, während eine Vervollständigung partial auf full kippt, eine neue ID erzeugt, und der Entzug läuft:

const suffix = eventType === 'refund' ? `-${refundScopeOf(isFullRefund)}` : ''
const readable = `${adapter}-${eventType}-${transactionId}${suffix}`

Und isFullRefund wurde ein Pflichtparameter statt eines optionalen, und das ist die eigentliche Sicherheitseigenschaft: Eine Aufrufstelle, die den Umfang vergisst, erzeugt nicht still eine ID im alten Format. Sie kompiliert nicht.

Die Lektion reicht über Rückerstattungen hinaus. Wenn dein Idempotenzschlüssel aus dem Ereignis abgeleitet wird, muss der Schlüssel jede Antwort tragen, die das Ereignis trägt. Deduplizierst du auf weniger, fallen zwei verschiedene Antworten zu einer zusammen.

Ein Agent rollt es aus und sieht deine Secrets nie

Das Repo bringt einen Setup-Assistenten mit, und sein Design dreht das Muster um, das die meisten “KI-fertigen” Setup-Anleitungen verwenden. Jedes verlässliche Setup-Werkzeug, wrangler login, gh auth login, create-next-app, funktioniert auf eine Art: Das Werkzeug führt und hält den Zustand, der Mensch antwortet. Eine Prosa-Anleitung, aus der ein Agent improvisiert, ist das Gegenteil, und Prosa ist eine ungetestete Oberfläche.

Also ist der Assistent ein Programm. Der Agent führt einen Befehl aus, npm run wizard:drive, gibt den Datensatz, den es ausgibt, wortgetreu wieder und reicht die Antwort zurück. Er wählt nie den nächsten Schritt, setzt nie einen Shell-Befehl zusammen und diagnostiziert nie abseits des Pfads.

Ein Datensatz ist eine Frage mit einer festen Auswahl, ein benanntes Freitextfeld, das von einem Dashboard abgelesen wird, oder ein manueller Schritt, den der Mensch mit dem einen Wort done bestätigt. Und done wird geprüft, nicht geglaubt: Wo der Treiber den echten Zustand prüfen kann, also Organisation, Team, Token, URL des ausgerollten Workers, tut er das, und eine fehlgeschlagene Prüfung führt zurück zu dem Bildschirm, dem die falsche Eingabe gehört, mit den bekannten Fehlerbildern als Daten angehängt. Der Lauf endet mit einem echten End-to-End-Testkauf, sodass “es funktioniert” eine Beobachtung ist, keine Hoffnung.

Der Teil, der mir am wichtigsten ist, ist das, was der Agent nicht sehen kann. Die Secret-Werte fügst du selbst in .dev.vars ein; das Deployment reicht diese Datei an wrangler, das sie direkt liest, also laufen die Werte nie durch den Agenten. Die Berechtigungsregeln, die dem Agenten das Lesen der Secrets-Dateien namentlich verweigern, sind im Repo eingecheckt, und ein Test pflanzt falsche Secrets und beweist die Verweigerung. Du kannst die Durchsetzung lesen, bevor du irgendetwas ausführst.

Rechne mit etwa einer Stunde von Anfang bis Ende, Dashboards inklusive. Der Assistent ist agentenunabhängig, und er braucht kein Spitzenmodell: Der Treiber besitzt die Reihenfolge und die Formulierungen, der Agent gibt nur wieder und reicht weiter. Meine eigenen Live-Läufe nutzten Claude Code auf Haiku, seiner günstigsten Stufe, und OpenCode auf einem kostenlos mitgelieferten Modell wie Big Pickle.

Was der AGPL-Core enthält, und was Pro ergänzt

Die Aufteilung folgt dem Bedarf, nicht der Beschneidung. Der Core auf npm ist die vollständige Engine: der Webhook-Router, der Stripe-Adapter, der Workflow für Freigabe und Entzug, die Claim-Seite, der Tippfehler-Pfad und der Assistent. Wenn du über Stripe verkaufst und gern selbst hostest, ist der Core das ganze Produkt, und das bleibt so.

Der Core exportiert außerdem jeden Baustein, den es braucht, um den Dienst per RPC in deinen eigenen Cloudflare-Funnel einzubetten, ganz ohne öffentliche Webhook-Route. Pro liefert das als fertige, unterstützte Service-Klasse; der Core gibt dir die Teile, um es selbst zusammenzusetzen.

Pro existiert für zwei Verkäufer: den, dessen Anbieter nicht Stripe ist, und den, der die Wartung der Webhooks nicht selbst besitzen will. Es ergänzt die anderen fünf Adapter, Paddle, Lemon Squeezy, Gumroad, Razorpay und Telegram Stars, darunter zwei Merchant-of-Record-Optionen, Paddle und Lemon Squeezy, für Verkäufer, die Steuern und Compliance vom Anbieter tragen lassen wollen. Es bringt außerdem einen gestalteten Storefront und Käuferseiten mit, und es wird gewartet: Anbieter ändern mit der Zeit Webhook-Nutzlasten, Ereignisnamen und Signaturschemata, und genau dem hinterherzulaufen ist die Arbeit, für die du bezahlst, damit du sie nicht hast.

Der Preis ist eine Einmalzahlung, die zwölf Monate Updates und Support enthält. Verlängerst du nie, läuft die Version, die du hast, für immer weiter: Dein Klon und dein ausgerollter Worker gehören dir, und nichts ruft zu Hause an, um nachzufragen.

Die Entscheidungshilfe, so schlicht ich sie formulieren kann: Stripe plus Selbsthosting, nimm den Core. Jeder andere Anbieter, ein Merchant of Record, oder ein Funnel, den lieber jemand anderes aktuell halten soll: Dafür gibt es Pro.

Was du dafür aufgibst

Kein OAuth heißt, der Benutzername wird eingetippt, und getippte Eingaben können falsch sein. Die Grenze zählt mehr als die Angst: Jede Einladung kostet einen abgeschlossenen Kauf, also kann niemand Zugänge farmen, und was bleibt, ist der Fehler eines einzelnen Käufers, ein Konto, ein Kauf, widerrufbar. Der Tippfehler-Pfad fängt die erkennbare Hälfte ab; ein Tippfehler, der das echte Konto einer anderen Person trifft, ist über das Ereignisprotokoll beantwortbar, nicht erkennbar, und das sage ich lieber offen, als eine Erkennung zu versprechen, die ich nicht habe.

Selbsthosting ist die andere Hälfte des Deals. Der Worker läuft auf deinem Cloudflare-Konto gegen deine GitHub-Organisation und dein Anbieter-Dashboard. Ist etwas falsch konfiguriert, sagen es dir die Prüfungen des Assistenten und der Ereignisstrom, aber es gibt keine Statusseite eines Anbieters, auf die du zeigen kannst. Die Marge zu besitzen und den Pager zu besitzen ist dieselbe Entscheidung.

Und der kostenlose Tarif hat eine Decke. Die 1.000 Schreibvorgänge pro Tag von KV bedeuten Hunderte Verkäufe pro Tag, weit über dem Normalbetrieb eines Code-Produkts, aber nicht über einer Spitze am Launch-Tag. Der Workers Paid Plan für 5 Dollar im Monat hebt das Schreibkontingent auf eine Million im Monat, und damit ist es keine nennenswerte Grenze mehr.

Wo du anfängst

Wenn du über Stripe verkaufst, klone repoaccess-core, starte den Assistenten mit dem Coding-Agenten, den du ohnehin nutzt, und rechne mit etwa einer Stunde. Die README trägt dieselbe Architektur, die dieser Artikel durchgegangen ist, mit den Details der Durchsetzung direkt neben dem Code.

Ist dein Anbieter Paddle, Lemon Squeezy, Gumroad, Razorpay oder Telegram Stars, oder willst du die Wartung abgeben, dann findest du die bezahlte Stufe auf der Produktseite von RepoAccess.

Ein letzter Fakt, weil es die stärkste Aussage ist, die ich über das Vertrauen in dieses Ding machen kann: Jede Kopie von Pro wird von RepoAccess selbst ausgeliefert. Du bezahlst, ein Worker lädt dein GitHub-Konto in das private Repository ein, und eine Rückerstattung würde die Einladung zurücknehmen. Die Auslieferungsschicht verkauft sich selbst auf dieselbe Art, wie sie alles andere verkauft.