GitHub App vs Personal Access Token for Automated Private-Repo Access

A fine-grained personal access token can live up to 366 days under an organization’s default policy. A GitHub App installation token lives for one hour. Both can add a buyer to the team that holds your private repo, and GitHub’s own guidance points long-lived integrations at the App. RepoAccess ships the token anyway, and this page says why, and when you should want the other key.

GitHub App vs personal access token for automated private-repo access: same calls, a different key

Selling access to a private repository comes down to team membership. The buyer joins the team that can read the repository, and leaves it when the money goes back. Everything a delivery worker does on GitHub is a variation of that, and GitHub accepts every one of those calls from both kinds of key.

The permission is the same too: one organization permission, Members, with write access. So the choice is not about capability. It is about how long a key lives, who it belongs to, and what it takes to keep it valid.

TL;DR

• Both a fine-grained PAT and a GitHub App installation token can grant and revoke team membership, with Members: write
• A fine-grained PAT lives up to 366 days and belongs to the account that made it
• An installation token lives one hour, belongs to no person, and is minted from a private key
• RepoAccess uses a fine-grained PAT today; an App suits several owners, turnover or a short-lived-credential rule

The calls a repo-access worker makes

Granting access is one request. Add or update team membership puts the buyer in the team; if they are not in the organization yet, GitHub emails them an invitation and the membership stays pending until they accept. RepoAccess makes that call like this:

const res = await fetch(
  `https://api.github.com/orgs/${org}/teams/${teamSlug}/memberships/${username}`,
  {
    method: 'PUT',
    headers: {
      Authorization: `Bearer ${env.GITHUB_TOKEN}`,
      Accept: 'application/vnd.github+json',
      'X-GitHub-Api-Version': '2022-11-28',
      'User-Agent': 'repoaccess-worker', // GitHub rejects requests without one
    },
  },
)

Revoking takes a few more. The worker removes the buyer from the team, lists the organization’s pending invitations and cancels theirs, and removes their organization membership once no team of yours still entitles them. Each of those endpoints lists fine-grained personal access tokens and GitHub App installation tokens among the tokens it accepts, and asks for Members: write.

No repository permission is involved, because the team carries the access to the repository. That does not make a leaked key harmless: Members: write can put any account into the team, so the key still guards your code.

The fine-grained PAT: one secret, one owner, one expiry

A fine-grained personal access token is created in your account settings, with your organization as the resource owner and Members read and write as its only organization permission. It goes into the worker as a single secret, and every request carries it as a bearer token, as in the call above.

Its lifetime is set by the organization. The default policy caps fine-grained tokens at 366 days, an owner can set a shorter maximum, and a token past it is blocked. When it expires, grants and revokes stop until you issue a new one with the same permission, so the date goes in a calendar the day you create it.

The token belongs to the account that created it. A token an owner creates needs no administrator approval, even where members’ tokens do, and it shares that account’s limit of 5,000 REST requests per hour. If that account ever lost owner rights, the token would lose them with it.

The organization-side settings that make this safe (fine-grained tokens allowed, approval required for members, a maximum lifetime) belong to the organization setup, and the boilerplate setup guide walks through them with the rest of it.

What a GitHub App installation token changes

A GitHub App holds a private key instead of a token. The worker signs a short JSON Web Token with that key, exchanges it for an installation access token, and uses that token for an hour. Nothing about it belongs to a person, so an owner leaving the organization does not break it.

The JWT rules are strict: RS256, the app’s client ID or app ID as the issuer, and an expiry no more than ten minutes ahead. In a Cloudflare Worker, Web Crypto does the signing, with one catch. GitHub hands you the private key in PKCS#1 format, and importKey only takes RSA private keys as PKCS#8, so the key is converted once before it becomes a secret:

openssl pkcs8 -topk8 -nocrypt -in app.private-key.pem -out app.pkcs8.pem

Then the exchange looks like this. It is not RepoAccess code; it is what the App path takes in a Worker:

const enc = new TextEncoder()

function b64url(bytes: Uint8Array): string {
  let s = ''
  for (const b of bytes) s += String.fromCharCode(b)
  return btoa(s).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
}

async function appJwt(clientId: string, pkcs8Pem: string): Promise<string> {
  const der = Uint8Array.from(atob(pkcs8Pem.replace(/-----[^-]+-----|\s/g, '')), (c) => c.charCodeAt(0))
  const key = await crypto.subtle.importKey(
    'pkcs8',
    der,
    { name: 'RSASSA-PKCS1-v1_5', hash: 'SHA-256' },
    false,
    ['sign'],
  )
  const now = Math.floor(Date.now() / 1000)
  const header = b64url(enc.encode(JSON.stringify({ alg: 'RS256', typ: 'JWT' })))
  const payload = b64url(enc.encode(JSON.stringify({ iat: now - 60, exp: now + 540, iss: clientId })))
  const sig = await crypto.subtle.sign('RSASSA-PKCS1-v1_5', key, enc.encode(`${header}.${payload}`))
  return `${header}.${payload}.${b64url(new Uint8Array(sig))}`
}

async function installationToken(jwt: string, installationId: string): Promise<string> {
  const res = await fetch(`https://api.github.com/app/installations/${installationId}/access_tokens`, {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${jwt}`,
      Accept: 'application/vnd.github+json',
      'X-GitHub-Api-Version': '2022-11-28',
      'User-Agent': 'my-worker',
    },
  })
  if (!res.ok) throw new Error(`installation token request failed: ${res.status}`)
  return ((await res.json()) as { token: string }).token
}

The installation token then replaces GITHUB_TOKEN in the same Authorization header. The private key becomes the secret that matters; GitHub calls it the single most valuable secret for an app, and a leaked key mints fresh tokens until you revoke it. The rate limit is the other gain: an installation starts at 5,000 requests per hour and can grow to 12,500, or 15,000 on GitHub Enterprise Cloud.

I have run the grant and revoke path with a fine-grained token only. GitHub lists installation tokens as accepted on the same endpoints, but its wording for the invitation step is written around an organization owner, so test the invitation of a brand-new buyer before you rely on an App for it.

Rate limits and the invitation cap at indie volume

Neither key’s hourly limit is what stops a small seller. A sale costs a handful of calls, a refund a few more, and 5,000 requests an hour is far above that. The limits worth knowing apply to both keys equally.

The first is the organization invitation cap. A free organization in its first month can send 50 invitations a day, and the ceiling rises to 500 once it passes a month or moves to a paid plan. A launch-day spike in a brand-new organization hits that ceiling whatever key sends the invitations. The second is GitHub’s secondary limit of no more than 80 content-creating requests per minute and 500 per hour, which a worker has to back off from with either key.

Why RepoAccess ships a fine-grained PAT

A seller sets RepoAccess up once, usually alone, often with a coding agent driving the steps. One token with one permission, pasted by the seller into the worker’s secrets file, is the shortest path that keeps the key out of the agent’s hands. An App adds a registration, an installation, a key conversion and a JWT exchange at least once an hour, for a benefit a solo organization owner mostly does not need.

The seller is also the organization owner. The failure a PAT invites, a departed employee’s token taking the integration down with it, does not exist when the only owner is the person selling. What remains is the expiry, and that is a yearly rotation with a date you already know.

So today RepoAccess authenticates to GitHub with a fine-grained personal access token only. The free core and RepoAccess Pro work the same way here, whichever payment provider sends the sale.

When a GitHub App is the better key

An App earns its extra setup in three situations. The first is an organization with several owners or staff who come and go, where a token tied to one person is a key that walks out of the door with them. The second is a security rule that forbids credentials living for months, where a one-hour token is the whole point.

The third is volume. An installation’s limit grows with the organization, while a personal token stays at 5,000 an hour shared with everything else that account does. None of these describes a solo seller with one organization and one product, which is who the fine-grained token suits.

Every provider page, and the other comparisons as they are written, is collected on the RepoAccess guides page.