If your content team publishes a website straight from a GitHub repository, one early decision quietly shapes everything that follows: how Acrosite connects to that repository. The GitHub App vs personal access token question is really a question about who owns the connection, how much access it grants, and how cleanly you can hand work off when people join or leave. This post explains both options in plain language so you can choose the connection that fits how your team actually works.
Acrosite is a Git-backed publishing platform, which means your pages and posts live as Markdown or MDX files with YAML frontmatter inside your own repository. Publishing commits those files for you. The connection that performs those commits is the thing we are comparing here, and getting it right keeps publishing reliable, auditable, and easy to maintain over time.
What the GitHub connection actually does
Before comparing the two methods, it helps to be precise about what the connection is for. When someone approves a draft in Acrosite, publishing validates the content, commits the Markdown or MDX file (with its frontmatter) to the configured branch and content path, saves the resulting commit SHA, and then fires your configured deployment trigger so the hosting provider can rebuild. Every one of those steps shows up in your Publish Logs, and the rebuild result shows up in your Deployment Logs.
All of that requires write access to a specific repository. The connection is the credential that grants that access. So the real comparison is not abstract security theory — it is about which kind of credential makes that day-to-day commit-and-deploy loop dependable. You can read the broader picture on the GitHub publishing feature page.
The GitHub App: a workspace-level connection
A GitHub App is an installable integration that an organization or repository owner authorizes once. Acrosite uses a GitHub App as the recommended way to connect, and the connection is held at the Workspace level, scoped to the connected repository — not tied to one person's individual GitHub login.
That distinction matters more than it first appears.
Ownership lives with the team, not a person
Because the App connection belongs to the Workspace, it survives staff changes. If the person who originally set up publishing leaves, the connection keeps working, because it was never anchored to their personal account. New Team Members can keep publishing without re-wiring anything.
Scope is narrow by design
A GitHub App is installed against the specific repository (or repositories) you choose, with a defined set of permissions. It does not borrow a human's full account access. This is least-privilege in practice: the connection can do the publishing job and little else, which keeps the blast radius small if anything goes wrong.
Cleaner auditability and offboarding
Two recurring headaches with content publishing are answering "what has access to this repo?" and "what do we do when someone leaves?" A workspace-level App answers both. The installation is visible in your GitHub organization's settings, its permissions are explicit, and offboarding a person does not disturb the publishing connection. You remove the human from the Team Members list in Acrosite; the App keeps running.
When you set up a GitHub App connection, choose the narrowest repository scope that still covers every Project you plan to publish. You can always extend it later, and a tight initial scope is the easiest one to audit.
The personal access token: the older alternative
A personal access token (PAT) is a credential generated from an individual GitHub user's account. It is the older path for connecting, and Acrosite still supports it, but it carries trade-offs worth understanding before you rely on it.
It is tied to a person
A PAT inherits the identity of the account that created it. That has two consequences. First, commits and access trace back to that individual rather than to a team-owned integration. Second, and more importantly, the connection's lifespan is bound to that person's account. If they leave, rotate their token, or lose access, publishing can break until someone re-establishes the connection.
Scope is coarser and easy to over-grant
Classic tokens in particular tend to be broad. It is common for a token to carry more reach than a single repository's publishing actually needs, simply because narrowing it is fiddly. Broad scope is not automatically dangerous, but it is harder to reason about and harder to audit than an App installation with explicit, repository-pinned permissions.
When a PAT still makes sense
None of this means a PAT is wrong. It can be a reasonable choice when:
- You are setting up a quick proof of concept and do not yet want to install an organization-level App.
- Your GitHub organization's policies make App installation slower to approve than generating a token.
- A single owner-operator runs everything and team handoff is not a near-term concern.
The honest summary: a PAT can get you publishing today, while a GitHub App is the option that ages well as your team and number of Projects grow.
A side-by-side comparison
Here is the practical contrast, point by point:
- Ownership — App: held at the Workspace, repository-scoped, team-owned. PAT: tied to one individual's account.
- Scope — App: explicit, repository-pinned permissions. PAT: often broader than the task needs.
- Least privilege — App: easy to keep tight. PAT: easy to over-grant.
- Offboarding — App: removing a person leaves publishing intact. PAT: a departing person can break the connection.
- Auditability — App: visible installation with stated permissions. PAT: scattered across personal account settings.
- Best fit — App: teams, agencies, and anything long-lived. PAT: quick starts and solo setups.
For agencies juggling many client repositories, the App's team-level ownership is usually the deciding factor. You can see how Acrosite compares with other tools on the comparison pages.
How the connection fits the rest of your workflow
The connection method does not change how your team produces content — it changes how dependable the final commit step is. Your editors still draft in the dashboard. Drafts stay private in the app until published, so nothing reaches the repository early. You can route work through the client review flow, where Client Reviewers see only the content assigned to them, comment, and Approve or Request Changes — all without any GitHub access of their own. Internally, work waits in the Review Queue.
When a draft is approved, scheduled publishing can hold it and commit at the chosen time rather than immediately, with no early commit to the branch. Whether the publish happens now or later, the same connection performs the commit, records the steps in Publish Logs, and triggers the rebuild for deployment visibility. A well-chosen connection is what makes that whole sequence boring and predictable — which, for publishing, is exactly what you want.
A simple setup checklist
Use this short sequence when you connect a Project's repository:
- Decide ownership: prefer the workspace-level GitHub App unless a PAT is clearly the better short-term fit.
- Scope the connection to only the repository the Project publishes to.
- Confirm the configured branch and content path (for example
content/posts/) match where your framework expects files. - Publish one test Content Item and check that Publish Logs show the commit SHA and a triggered deployment.
- Review your Team Members and Client Reviewers so access matches who should actually touch the content.
A clean connection, scoped tightly and owned by the team, means publishing keeps working no matter who is on the roster next quarter.