How to manage blog posts on a Git-backed website without editing Markdown

If you want to manage blog posts without editing Markdown, you are not alone. Markdown and YAML frontmatter make excellent storage: they are plain text, they version cleanly in Git, and they keep your content portable and free of database lock-in. But as an authoring surface they are unforgiving. A misplaced colon in the frontmatter, an unquoted string, a stray indent, or a forgotten closing fence can break a build, and most writers should never have to think about any of that. The good news is that you can keep all the benefits of file-based content while giving your team a normal editor.

Acrosite is built around exactly this split. Your website content lives in your own GitHub repository as Markdown or MDX files with YAML frontmatter, but the people writing those posts work in a clean dashboard instead of editing raw files. This article walks through how a Posts content type, a real editor, and typed frontmatter fields come together, and how a post moves from draft to review to a published commit.

Why Markdown is great storage but poor authoring UX

Storing content as flat files in Git is a genuinely good architecture. Every change is a commit, so you get history, diffs, branches, and rollback for free. There is no proprietary database to export from, and your content moves with your repository. Static and Git-backed frameworks read those files at build time and render fast, cacheable pages.

The problem is that the storage format and the writing experience are not the same job. Asking a marketer or a subject-matter expert to open a .md file in GitHub and hand-edit frontmatter is asking them to be careful about syntax that has nothing to do with their actual work. Common failure modes include:

• Breaking YAML with an unquoted value that contains a colon or a leading number.
• Forgetting a required field like title or date, so the build fails or the page renders wrong.
• Pasting formatted text from a document and dragging broken HTML into the body.
• Editing the wrong file, or committing directly to the production branch by accident.

None of these are content problems. They are interface problems. The fix is to keep the files exactly as they are and put a proper editor in front of them.

The Posts content type and typed Custom Fields

In Acrosite, a blog is modeled as a Posts content type. Posts is one of the built-in types alongside Pages, and you can also define your own Custom Content Types for things like case studies, release notes, or team bios. Each type carries a set of Custom Fields, which are the typed inputs that map directly to your frontmatter.

Custom Fields are where the authoring experience gets safe. Instead of a blank text file, a writer sees labeled inputs with the right control for each kind of data:

• A text field for the title and slug.
• A rich text or block editor for the body.
• An image field for the cover image, with an upload instead of a hand-typed path.
• A dedicated SEO field for the meta description and related metadata.
• Date and select fields for things like publish date, author, or category.

Because each field is typed, the form can validate as the writer goes. A required title cannot be left empty, a date is always a valid date, and the frontmatter that Acrosite generates is always well-formed. Individual entries created from a type are Content Items, so each blog post you see in the dashboard is a Content Item under your Posts type. You can read more about modeling your content this way on the Custom Content Types page.

What the writer sees versus what gets committed

The key mental model is that the editor and the file are two views of the same thing. The writer fills in fields and writes in a normal editor. When the post is published, Acrosite serializes those fields into YAML frontmatter and the body into Markdown, then commits the file to your repository.

Here is the kind of file that gets written to your repo, even though the author never typed any of the syntax by hand:

---
title: "How we cut our build time in half"
slug: cut-build-time-in-half
date: 2026-06-04
author: "Priya N."
category: Engineering
description: "A short walkthrough of the caching changes that made our deploys faster."
coverImage: /images/blog/build-time.jpg
draft: false
---

Our deploys used to take nearly twelve minutes. Here is what we changed.

## The bottleneck

...

The writer experienced that as a title input, a date picker, an author select, an image upload, an SEO description box, and a body editor. The colons, quotes, indentation, and fence rules are handled for them. That is the whole point of being able to manage blog posts without editing Markdown directly: the structure is enforced by the form, not by the author's discipline.

Where posts live: Workspace, Project, and repository

Before a post can be committed anywhere, Acrosite needs to know which repository and path it belongs to. The structure is straightforward. A Workspace contains Projects, and each Project maps to one client website and its repository. Clients group related work so an agency can keep multiple brands organized.

The connection to GitHub is held at the Workspace level through a GitHub App connection scoped to the connected repository, rather than tied to one person's personal account. That means a Team Member can leave and the publishing pipeline keeps working. Each Project is configured with a branch and a content path, for example content/posts/, so when a Posts item is published it lands in a predictable, reviewable location. If you want the deeper mechanics of how commits are made, the GitHub publishing feature page covers it in detail.

A quick setup checklist

1. Connect the repository to your Workspace using the GitHub App connection.
2. Create or open the Project that maps to the target website.
3. Confirm the publish branch and the content path for Posts.
4. Define the Custom Fields on your Posts type so they match your frontmatter.
5. Invite the Team Members and Client Reviewers who need access.

The review, schedule, and publish flow

Once a post is written, it usually needs a second set of eyes before it ships. Acrosite handles this with an internal Review Queue and, separately, with Client Reviewers.

Internal collaborators are Team Members with roles such as Owner or Admin. A draft can be sent to the Review Queue so the right person can check it before it goes live. When a client needs to sign off, you invite Client Reviewers per Project. Client Reviewers see only the content assigned to them, can read drafts, leave comments, and either Approve or Request Changes. They have no GitHub access, no billing visibility, and no access to Workspace settings, which keeps client involvement focused on the content itself. See the client review page for how that approval loop is structured.

A typical lifecycle looks like this:

1. A writer drafts a Post as a Content Item using the typed fields.
2. The draft goes to the internal Review Queue, or to an assigned Client Reviewer.
3. A reviewer comments and either approves or requests changes.
4. Once approved, the post is published now or scheduled for later.
5. Publishing commits the Markdown file with frontmatter to the configured branch and path.

Scheduled publishing is useful when timing matters. With Scheduled publishing, the approved draft is held inside the app and committed at the chosen time. There is no early commit sitting on your branch ahead of schedule, so your repository history reflects when content actually went live. If you manage a regular cadence, the Content Calendar gives you a single view of what is queued and when.

After the commit: deployment and Publish Logs

Committing the file is not always the last step. Most Git-backed sites need to rebuild before readers see the change. After a commit, a configured deployment trigger profile tells your hosting provider to rebuild, either manually or automatically. This is deployment visibility, and it means you can see that a publish actually reached the live site rather than guessing.

Acrosite records what happened at each stage. Publish Logs capture each publish attempt's steps: content validated, committed to GitHub, commit SHA saved, and deployment triggered. Importantly, these logs do not expose tokens, hook URLs, or raw provider payloads. If a publish fails, you can retry it where it is safe to do so. Deployment Logs record the results of the deployment trigger itself, so a failed rebuild does not stay hidden. The Publish Logs page describes what is recorded and what stays redacted.

This combination is what makes a file-based blog manageable for a non-technical team. The content is stored as clean Markdown in your own repository, the writing happens in a real editor, review and scheduling are first-class, and every publish leaves an auditable trail. Acrosite works well with Next.js and other Git-backed and static frameworks, and offers Solo, Creator, Agency Starter, Agency Pro, and Enterprise plans with a 14-day free trial.