> ## Documentation Index
> Fetch the complete documentation index at: https://docs.macropay.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Automate Private GitHub Repo(s) Access

> Grant and revoke private GitHub repo access automatically on every purchase, subscription, and cancellation.

<img src="https://mintcdn.com/macrodeepinc/S4T0jM7ZWV5HVLft/assets/features/benefits/github/hero.png?fit=max&auto=format&n=S4T0jM7ZWV5HVLft&q=85&s=d3974e8b0c1c8da23745f8a1da9c6514" width="2400" height="1374" data-path="assets/features/benefits/github/hero.png" />

Ship code as a product. When a customer buys or subscribes, Macropay invites them as a collaborator on the private repositories you choose. When they cancel, access is pulled — no scripts, no spreadsheets, no manual invites to chase.

Because Macropay is the merchant of record, the same flow also collects and remits sales tax/VAT on the sale and keeps that liability off your books, so you can focus on the repo and not the paperwork.

## What you can sell

GitHub repository access is delivered as a **benefit** (entitlement) attached to any product — one-time or subscription:

* **Subscriptions** → access granted on first payment, revoked the moment the subscription ends.
* **One-time products** → buy once, keep collaborator access for life.
* **Multiple repos** → attach several GitHub benefits to one product to bundle repositories from your organization(s).

Common scenarios:

| Use case                       | How it works                                                       |
| ------------------------------ | ------------------------------------------------------------------ |
| Sponsorware                    | Gate a repo behind a sponsorship tier until a funding goal is hit. |
| Premium courses & starter kits | Sell the source alongside lessons, templates, and assets.          |
| Open-core / self-hosting       | Charge for the private enterprise repo on top of your OSS core.    |
| Early access                   | Let paying users see feature branches before they land upstream.   |
| Sponsor-only discussions       | Keep issues and Discussions private to paying collaborators.       |

<Tip>
  Selling access to an AI agent or coding tool? Pair this benefit with [usage-based billing](/features/usage-based-billing/introduction) to charge for the repo *and* meter what the agent does once they're inside.
</Tip>

## Create the benefit

<Steps>
  <Step title="Open Benefits">
    In the dashboard sidebar, go to **Benefits** and click **+ New Benefit**.
  </Step>

  <Step title="Choose the type">
    Set **Type** to **GitHub Repository Access**.
  </Step>

  <Step title="Connect your GitHub account">
    Click **Connect your GitHub Account** and install the dedicated Macropay GitHub App on the repositories you want to automate. After authorizing, you're returned to the benefit form, now connected.
  </Step>

  <Step title="Pick the repository and role">
    Select the organization repository and the collaborator role to grant. Save, then attach the benefit to a product.
  </Step>
</Steps>

<Info>
  **Why connect GitHub a second time and install a separate app?**

  Inviting collaborators requires permission to manage repository access — a sensitive scope. GitHub Apps can't request permissions progressively, so rather than ask *every* user for repo-management rights during normal GitHub login, this feature ships as a standalone app you install only on the repos you actually sell.
</Info>

## Choose a repository

Pick the organization repository you want to automate invites for.

<Info>
  **Why organization repos only — not personal ones?**

  GitHub doesn't offer granular collaborator permissions on personal repositories; every collaborator effectively gets write access, meaning they could push commits and cut releases. To keep your code safe, personal repos are off by default. Need it anyway? Reach out and we can enable it for your account.
</Info>

## Choose a role

Select the access level granted to each collaborator:

| Role     | Recommendation                                                    |
| -------- | ----------------------------------------------------------------- |
| **Read** | **Default — use this.** Read-only access covers \~99.9% of cases. |
| Triage   | Advanced; manage issues/PRs without code access.                  |
| Write    | Discouraged — grants push access.                                 |
| Maintain | Discouraged — repo management without admin.                      |
| Admin    | Strongly discouraged — full control.                              |

Anything above **Read** is discouraged unless you have a specific need and fully understand the impact. See the [GitHub role reference](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization#permissions-for-each-role) for the exact permissions behind each role.

<Note>
  Even with Read access, a collaborator can open a pull request ([details](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request)).
</Note>

<Warning>
  **Paid GitHub organizations are billed per seat.** GitHub counts each collaborator as a seat and charges your plan accordingly. Either run a free organization plan, or price your product high enough to cover the GitHub seat cost you'll incur for every buyer.
</Warning>