Every developer who builds Git-backed sites eventually hits the same wall. The site is finished, the static framework is fast, the repository is clean — and then the client asks how they update the homepage copy or publish next week's blog post. The honest answer is usually "send me the change and I'll commit it," which turns a developer into a permanent content middleman. The goal of this guide is to show how to hand off content management without writing a bespoke CMS for every project, so non-technical people can publish on their own while the content stays in the repository and the framework you already chose.

Acrosite exists for exactly this handoff. It is a Git-backed content publishing platform: website content lives as Markdown or MDX files with YAML frontmatter inside the client's own GitHub repository, and non-technical people publish through a dashboard instead of editing files directly in GitHub. You connect the repo once, model the content, invite the right people, and step back from the day-to-day editing loop — without giving up the parts a developer needs to keep controlling.

Why building a CMS per site is the wrong default

The instinct to build a small admin panel for each Git-backed site is understandable, but it scales badly. Every project ends up with its own login system, its own forms, its own validation, its own commit logic, and its own deployment glue. Multiply that across a handful of client sites and you are now maintaining several half-finished content tools instead of shipping websites.

A custom CMS also tends to drift away from the repository as the source of truth. The moment editing happens in a database that later syncs to Git, you have two systems that can disagree, and reconciling them becomes your problem. The cleaner model keeps the files in the repo authoritative and treats the editing surface as a controlled way to write to them.

Note

The test for any handoff tool is simple — if you deleted the editing layer tomorrow, your site should still build from the repository exactly as it does today. Acrosite is designed so that the Markdown and frontmatter in the repo remain the canonical content.

Step one: connect the repository with a GitHub App

The connection between Acrosite and the repository is what makes publishing possible, so it is worth setting up deliberately. The recommended path is a GitHub App connection held at the Workspace level and scoped to the connected repository, rather than a connection tied to one person's individual account. (A personal access token is the older alternative, but the GitHub App is the path to prefer.)

Holding the connection at the workspace level has a practical payoff for developers and agencies: it survives staff changes. If the person who first wired up publishing leaves, the connection keeps working because it was never anchored to their personal login. The scope is also narrow by design — the App is installed against the specific repository you choose, so it can do the publishing job and little else. You can read the broader picture on the GitHub publishing feature page, and the trade-offs between the two methods on the GitHub App vs personal access token post.

Step two: model content with types and fields

Once the repo is connected, you decide what kinds of content the client can create and what shape each one takes. Acrosite's content model has three building blocks:

  • Posts for blog entries, news, or any reverse-chronological stream.
  • Pages for standalone pages like About or Pricing.
  • Custom Content Types for anything structured that does not fit a generic post or page — case studies, team members, events, product entries.

On any content type you define Custom Fields, which are typed fields such as text, rich text, image, or a dedicated SEO field. Typed fields are what make the handoff safe: instead of letting a client free-type into a raw Markdown file and hope the frontmatter stays valid, you decide the schema once and they fill in structured inputs. Each entry they create is a Content Item.

A practical example: a case study type

Suppose a client site needs case studies. As the developer you define a Custom Content Type with fields like a text title, a short text client name, a rich text body, an image for the hero, and an SEO field for the meta description. When the content is published, it commits as a Markdown file with frontmatter that mirrors those fields:

---
title: Launching a storefront for a retail client
clientName: Northbridge Retail
heroImage: /images/case-studies/northbridge.jpg
seoDescription: How we cut page weight and improved conversion.
publishedAt: 2026-06-01
---

The full case study body, written as Markdown by the client...

Your framework reads that frontmatter exactly as it would if you had hand-authored the file. Nothing about the build changes. See Custom Content Types for how this maps end to end.

Step three: hand non-technical users a safe dashboard

With the repo connected and content modeled, the client edits through the Acrosite dashboard rather than GitHub. Drafts are private in the app until published — a client can work on a post over several days, and nothing reaches the branch until it is deliberately published. Publishing commits the Markdown or MDX file (with its frontmatter) to the connected repo on the configured branch and content path, for example content/posts/.

This is the heart of the handoff. The client never sees a commit dialog, a branch selector, or a merge conflict. They see a form built from the fields you defined, a clear draft-versus-published status, and a publish action. The developer is no longer the bottleneck for routine copy changes, and the repository still receives well-formed commits.

Where Client Reviewers fit

If the workflow includes a sign-off step, Client Reviewers are invited per project and see only the content assigned to them. They can read drafts, comment, and either Approve or Request Changes. Crucially, they have no GitHub access, no billing visibility, and no workspace settings access — so you can bring a client stakeholder into the review loop without exposing the repository or the account. Internally, work waiting on action sits in the Review Queue. The full model is on the client review page.

Step four: control timing without early commits

A common reason developers stay involved is timing — a client wants a post to go live Monday morning, not whenever they happen to finish it. Acrosite handles this with Scheduled publishing: an approved draft is held in the app and committed at the chosen time, with no early commit to the branch beforehand. The repository only changes when the scheduled moment arrives, which keeps the Git history honest and avoids "published but hidden" hacks in the codebase.

For teams planning ahead, the Content Calendar gives a single view of what is scheduled and when, so editorial planning happens in one place instead of a spreadsheet plus a series of developer reminders.

What the developer keeps control of

Handing off editing does not mean handing off everything. The handoff is deliberately partial, and the parts that matter to engineering stay with you:

  1. The repository remains the source of truth — content is just Markdown and frontmatter you can read, diff, and version like any other file.
  2. The framework is yours to choose; Acrosite works well with Next.js and other Git-backed or static frameworks, and it does not impose a runtime on your build.
  3. You define the content types, the Custom Fields, the branch, and the content path, so the schema of what gets committed is set by engineering, not by whoever is editing.
  4. Deployment visibility stays observable: after a commit, a configured deployment trigger profile tells the hosting provider to rebuild, either manually or automatically.
  5. Every publish is auditable. Publish Logs record each attempt's steps — validated content, committed to GitHub, commit SHA saved, deployment triggered — without exposing tokens, hook URLs, or raw provider payloads, and failed publishing can be retried where it is safe. Deployment Logs record the rebuild trigger results.

Internally you also still manage Team Members with roles such as Owner and Admin, while the structure stays tidy: a Workspace contains Projects, each Project maps to a client website and repository, and Clients group related work. That structure is what lets one agency hand off content on many sites at once without the per-site CMS sprawl.

A clean handoff checklist

Before you call a site "handed off," confirm the basics are in place:

  • The GitHub App connection is installed at the Workspace level and scoped to the right repository.
  • Posts, Pages, and any Custom Content Types are defined with the Custom Fields the client actually needs.
  • The configured branch and content path match what the framework reads at build time.
  • The deployment trigger profile is set so commits cause a rebuild.
  • The right people are invited — Team Members for internal collaborators, Client Reviewers for sign-off only.
  • You have confirmed a test publish appears correctly in Publish Logs and triggers a deployment.

Once those boxes are ticked, the routine content work belongs to the people who own the content, and your involvement drops to the engineering decisions that genuinely need a developer. If you are weighing this against other approaches, the compare and pricing pages help size it for your projects, and there is a 14-day free trial across the Solo, Creator, Agency Starter, Agency Pro, and Enterprise plans.

Frequently asked questions

No. That is the pattern this approach is meant to replace. You connect the repository once, define the content types and fields in Acrosite, and the editing dashboard is generated from that model — so you avoid maintaining a separate bespoke CMS per project.
In the client's own GitHub repository, as Markdown or MDX files with YAML frontmatter. Acrosite commits those files for non-technical editors, but the repository remains the source of truth, so your framework builds from it exactly as before.
Yes. Clients and editors work in the dashboard, where drafts stay private until published. Publishing commits the file to the configured branch and content path on their behalf, so they never see commits, branches, or merge conflicts.
By defining Custom Fields with specific types on each content type. Editors fill in structured inputs rather than hand-editing raw frontmatter, so the committed Markdown stays well-formed and matches what your framework expects.
You keep the repository as the source of truth, the choice of framework, the content schema, the branch and content path, the deployment trigger, and full visibility through Publish Logs and Deployment Logs — without exposing tokens or raw provider payloads.