Why agencies should not give clients GitHub access for content updates

The fastest way to create a security problem on a client website is to hand over client GitHub access so they can "just update the copy themselves." It sounds efficient. In practice, repository access is the single broadest permission you can grant on a Git-backed site, and you cannot narrow it down to only the content. Once a non-technical stakeholder has commit rights to the repo, they also have visibility into application code, deployment configuration, environment references, and the full commit history — none of which they should ever need to fix a typo on the homepage.

This article walks through why repo access cannot be scoped to content alone, the bottleneck and risk that GitHub-for-everyone creates, and a safer pattern: a workspace-held GitHub App connection paired with Client Reviewers and Scheduled publishing, so clients get a clean content path without ever touching the repository.

Why client GitHub access can't be scoped to "just content"

GitHub permissions are coarse by design. A repository collaborator with write access can push to branches, open and merge pull requests, and read everything in the tree. There is no native "content folder only" role that meaningfully restricts a human collaborator to a single directory. Branch protection rules and CODEOWNERS can gate merges, but they do not hide the rest of the codebase, and they assume the person already understands Git well enough not to cause damage.

When you give a client a seat in the repo, here is what comes bundled with the content they wanted to edit:

• Application code — components, build scripts, and framework configuration they have no reason to see or change.
• Deployment configuration — hosting settings, build commands, and trigger definitions that, if altered, can break the live site.
• Environment references — variable names and config files that point at the project's infrastructure.
• Full commit history — every past change, author, message, and reverted experiment, permanently readable.

Even a careful client working only in content/posts/ is one bad merge, force-push, or accidental file deletion away from an outage. The risk is not malice; it is that a content editor has been handed a developer tool and the consequences scale with the whole repository, not with the size of their edit.

The bottleneck and the risk, side by side

Teams usually land in one of two bad places. Either they give clients repo access and inherit the security and stability risk above, or they refuse access and become a manual relay for every content change.

The relay model has its own cost. Every edit becomes a ticket: the client emails copy, someone on the team pastes it into Markdown, commits it, and waits for a build. Small fixes queue behind larger work. Clients lose visibility into whether their change shipped. Multiply that across a roster of sites and the content workload quietly becomes a staffing problem.

So the real question is not "access or no access." It is how to give clients a direct, self-serve path to their own content while the repository — code, config, history, and credentials — stays entirely out of reach. That separation is exactly what a Git-backed publishing layer is for. You can see how the pieces fit together on the how it works overview.

A workspace-held GitHub App, not personal repo seats

Acrosite connects to GitHub through a GitHub App held at the Workspace level, scoped to the connected repository, rather than through individual personal accounts. This is the recommended path over an older personal access token. The distinction matters for client safety:

1. The connection belongs to the Workspace, not to any one person, so content can be published without minting a GitHub seat for every editor or stakeholder.
2. The App is scoped to the specific repository the Project maps to, so its reach is defined once by the team that set it up.
3. Clients and most editors never authenticate to GitHub at all — they work entirely inside the Acrosite dashboard.

In Acrosite's structure, a Workspace contains Projects, each Project maps to a client website and its repository, and Clients group related work. The GitHub publishing connection lives at the Workspace level and is applied per Project. The result is that the credential surface is small and centrally managed, instead of being sprayed across many individual GitHub accounts you later have to audit and revoke. You can read more on the GitHub publishing feature page.

What a client can and cannot do

This is the heart of the model. Client Reviewers are invited per Project and see only the content assigned to them. They are not repository collaborators, and the boundary is enforced by the product, not by trust.

What a Client Reviewer can do

• Read the drafts assigned to them within their Project.
• Leave comments on specific content.
• Approve a draft, or Request Changes with feedback.

What a Client Reviewer cannot do

• They have no GitHub access — no repo, no code, no commit history, no branches.
• They have no billing visibility.
• They have no Workspace settings access.
• They cannot see content from other Projects or other Clients.

Internally, your Team Members — collaborators with roles such as Owner/Admin — manage the actual content. Drafts stay private inside the app until published; they are not committed to the repository while in progress. The internal Review Queue gives the team a single place to see what is waiting on client sign-off, and Client Reviewers interact only through their assigned items.

How content reaches the repo without anyone touching it

With this separation in place, publishing becomes a controlled, observable event rather than a manual Git operation. A typical workflow looks like this:

1. A Team Member drafts a Content Item — a Post, a Page, or an entry of a Custom Content Type — using the Custom Fields defined for that type.
2. The assigned Client Reviewer reads it and either Approves it or Requests Changes with comments.
3. Once approved, the team publishes. Publishing validates the content and commits the Markdown/MDX file, with its YAML frontmatter, to the connected repository on the configured branch and content path.
4. After the commit, a configured deployment trigger profile prompts the hosting provider to rebuild — manually or automatically — giving the team Deployment visibility into what shipped.

A published Content Item lands in the repo as a clean file. For example, a blog Post might be committed to content/posts/ with frontmatter like this:

---
title: "Spring Product Update"
slug: spring-product-update
date: 2026-04-12
status: published
description: "What changed this quarter and why it matters."
---

Body content in Markdown lives here.

The client never saw that file, the branch, or the commit. They saw a readable draft and clicked Approve. This pairs naturally with Scheduled publishing: an approved draft is held in the app and committed at the chosen time, so there is no early commit sitting on the branch ahead of its publish date. For recurring or seasonal work, the Content Calendar keeps the pipeline visible.

Keeping an audit trail without exposing internals

Removing client GitHub access does not mean losing accountability — it improves it. Every publish attempt is recorded in Publish Logs, which capture the steps that ran: content validated, committed to GitHub, commit SHA saved, deployment triggered. Crucially, these logs do this without exposing tokens, deploy hook URLs, or raw provider payloads. If a publish fails, it can be retried where safe, and Deployment Logs record the results of deployment triggers separately.

So you end up with a stronger record than ad-hoc repo access ever provided: a per-Project history of who approved what, when it was committed, and how the deployment responded — readable by the right people, with secrets and infrastructure details kept out of the interface entirely. If you have specific compliance questions, the security overview is a good next read.

A quick checklist before you ever add a client to a repo

• Do they actually need to change code, or only content? If only content, repo access is the wrong tool.
• Can the content path and branch be configured once, then published to without manual Git? With a Git-backed dashboard, yes.
• Is there a way for the client to approve work without seeing the codebase? Client Reviewers cover this.
• Will every change be logged without leaking credentials? Publish Logs and Deployment Logs handle that.

If the honest answer is "they only touch content," there is no reason to put the entire repository — and your deployment configuration and history — behind a single shared login.