How to Give Your Astro Site a Visual Editor for Non Technical Users

You can give a non-technical user the ability to edit content on an Astro site without touching a single line of code — in about ten minutes. Connect Sitepins to your Astro GitHub repository, point it at your src/content/ folder, and invite your editor by email. They get a clean visual interface; you keep full Git control. Every edit they make becomes a commit in your repository and triggers your existing Vercel or Netlify deploy pipeline automatically.

This tutorial covers the complete setup for Astro sites and the exact editor experience your non-technical user will have once it’s live.

TL;DR — Key Takeaways

• Astro sites built with Content Collections work out of the box — no astro.config.mjs changes required
• Editors see a clean form interface, not code or file trees
• Every save becomes a Git commit — your deploy pipeline triggers automatically
• Editors do not need a GitHub account
• 34% of Sitepins users build on Astro — the CMS is purpose-tested against Astro’s content model
• Setup takes 10–15 minutes; editor onboarding takes under 5

What “Visual Editor” Means for an Astro Site

A visual editor for an Astro site is a separate web interface — accessed by your editor at a URL, not in your codebase — that lets them create, edit, and publish content without touching Markdown files, frontmatter syntax, or Git.

Under the hood, the editor is writing directly to the same .md and .mdx files in your src/content/ directory that you work with as a developer. The difference is presentation: instead of opening a .md file in VS Code and editing raw text, your editor opens a form with labelled fields (Title, Date, Body, Featured Image) and a rich text toolbar.

When they save, the CMS commits the updated file to your GitHub or GitLab repository. From your side, it looks identical to a commit you made yourself — the file changes are in Git history, reversible, and auditable.

What it is not: A visual editor for Astro is not a page builder, drag-and-drop layout tool, or site redesign interface. It manages content — words, images, metadata — not design or code structure.

Why Non-Technical Editors Struggle with Astro by Default

Astro is a developer-first framework. Its content layer — Content Collections, frontmatter schemas defined in src/content/config.ts, Markdown and MDX files — is powerful and predictable for developers. For non-technical editors, it presents three specific problems:

1. No editing interface ships with Astro.Astro has no built-in CMS panel or admin UI. A non-technical user handed access to a GitHub repository will see a file tree, not an editorial interface. They cannot edit content without understanding Git, Markdown syntax, and file structure.

2. Frontmatter syntax is fragile for non-developers.A content entry in Astro looks like this:

---
title: "How We Built Our Product"
date: 2026-03-15
description: "A case study about our build process."
image: "/images/product-build.jpg"
draft: false
tags: ["product", "engineering"]
---

Body content starts here...

A non-technical editor making a direct edit to this file on GitHub can easily break frontmatter syntax — a missing quote, a misformatted date, a stray character — causing a build failure that shows nothing to the editor but breaks the entire site deploy.

3. Publishing requires understanding Git.Even if an editor successfully edits a file in GitHub’s web interface, they need to understand what “commit to main” means, what a pull request is, and why their changes may not appear immediately if they’re on a branch.

A dedicated CMS layer removes all three problems.

What You Need Before You Start

• An Astro site with content in src/content/ using Content Collections, or plain .md files in src/pages/
• The site hosted on GitHub or GitLab (public or private repository)
• A Sitepins account — start free at sitepins.com
• Your Astro site already deployed on Vercel, Netlify, or Cloudflare Pages (optional, but required for the automatic deploy pipeline)
• Your editor’s email address

You do not need to install any npm packages, modify your astro.config.mjs, or make any changes to your repository before starting.

Step-by-Step: Connect Sitepins to Your Astro Site

Step 1: Create a project in Sitepins

Sign in to app.sitepins.com and click New Project. Sitepins will prompt you to connect a Git provider. Choose GitHub or GitLab and authorise the OAuth connection. You’ll see a searchable list of your repositories.

Select the repository containing your Astro site and click Continue.

Sitepins reads your repository’s file structure at this point. It does not commit anything to your repo during setup.

Step 2: Select your content folder

Sitepins shows your repository’s directory tree. Navigate to the folder containing your content files.

For a standard Astro Content Collections project:

• Choose src/content/blog/ to give editors access to blog posts only
• Choose src/content/ to expose all collections (blog, docs, authors, etc.)

Click Confirm. Sitepins scans the folder, detects your .md and .mdx files, and lists them as editable entries.

If you have multiple content types: You can add multiple folders as separate sections. Editors see them as labelled groups in the sidebar — Blog, Docs, Authors — and switch between them with one click.

Step 3: Confirm your content schema

Sitepins reads the frontmatter fields in your existing content files and builds an editing form automatically. You do not need to define a CMS schema separately.

Check that the detected fields match what you’d expect:

• title → single-line text field
• date → date picker
• description → multi-line text area
• image → media picker with upload support
• tags → tag-adding widget
• draft → toggle switch

If you use a Zod schema in src/content/config.ts, required fields appear in every entry’s form and cannot be saved empty. Optional fields appear but can be left blank.

Step 4: Set your media folder

Choose the folder where uploaded images should be stored. Common choices for Astro projects:

• public/images/ — served directly at /images/ in the built site; works for frontmatter image paths referenced by URL
• src/assets/ — processed by Astro’s built-in image optimisation; works for images imported in components

When an editor uploads an image, Sitepins commits it to this folder and inserts the correct path into the content field automatically. All media is stored in your repository — no external CDN or third-party asset service is added.

Step 5: Invite your editor

Open Settings → Team → Invite member in your Sitepins project. Enter your editor’s email address and assign the Editor role. Editor access allows them to create, edit, and delete content entries. It does not allow access to project settings, repository configuration, or billing.

Click Send invite. Your editor receives an email with a setup link. They create a password and access the editor directly — no GitHub or GitLab account required.

Setup is complete on your end.

What Your Editor Sees and How They Work

Your editor’s experience is entirely separate from your development workflow. Here’s what they encounter.

​

​

The content list

After logging in, the editor sees a clean sidebar with their content sections (Blog, Docs, etc.). Clicking a section shows a list of all content entries with titles, publish dates, and draft status. Entries can be filtered by status and sorted by date.

There is no file tree, no raw Markdown, no Git interface.

Opening and editing a post

Clicking an entry opens the editing view. The frontmatter fields appear as a structured form on the left (or top on smaller screens); the body content appears in a rich text editor.

​

​

The body editor works like a simplified word processor:

• Visual mode: Toolbar with bold, italic, headings H1–H4, links, ordered and unordered lists, blockquotes, inline code, code blocks, and image insertion. No Markdown knowledge required.
• Markdown mode: Raw Markdown for editors who prefer it. Both modes stay in sync — switching between them preserves all content.

Adding images

The editor clicks the image icon in the toolbar or the image field in the frontmatter form. A media panel opens showing previously uploaded images; they can drag in a new file or click to browse. Sitepins handles the upload, Git commit, and path insertion without any developer input.

Saving and publishing

When the editor clicks Save, Sitepins commits the changed file to your repository’s default branch (main or master). There is no separate “publish” step visible to the editor — save means the content goes live as soon as your deploy pipeline completes (typically 1–2 minutes on Vercel, 1–3 minutes on Netlify).

The editor sees a success confirmation with a note that the site is updating. They do not see a deploy log, build output, or any technical feedback.

Creating new posts

The editor clicks New Entry in the content section. A blank form opens with all the frontmatter fields from your schema. They fill in the fields, write the body, and save. Sitepins creates the .md file in your src/content/blog/ folder (or wherever you pointed it), with a filename generated from the entry title.

How Edits Flow Back to Your Codebase

Every save in Sitepins creates a standard Git commit. From your side, it looks identical to any other content commit:

1. Editor clicks Save in Sitepins
2. Sitepins creates a commit: Update: "Post title" on your main branch
3. The commit appears in your GitHub or GitLab repository history with the changed .md file
4. Vercel, Netlify, or Cloudflare Pages detects the push and triggers a build
5. astro build runs, and your updated content is deployed to the CDN
6. The live site reflects the editor’s changes — typically within 1–3 minutes

From your local machine, running git pull brings the editor’s content changes into your working directory as normal files in src/content/. The files are identical to what you’d write yourself — no proprietary format, no CMS-specific metadata appended.

Git history stays clean. Sitepins commits are clearly labelled. You can git revert any individual editor commit to undo a specific content change. You can git blame a content file to see the full edit history.

Using Branches to Add a Review Step

By default, Sitepins commits directly to your main branch — editor saves go live immediately. If your workflow requires review before publishing, you can configure a staging branch.

How to set up a review workflow:

1. Create a staging branch in your GitHub repository
2. In Sitepins Settings → Project → Branch, change the target branch from main to staging
3. Editors now save to staging. Their changes do not trigger a production deploy until you (or they) merge the branch.

When an editor is ready to publish, Sitepins lets them open a pull request from staging → main directly from the CMS interface — no GitHub knowledge needed. You review the PR and merge it when ready. Vercel or Netlify detects the merge and deploys the production build.

This workflow is useful for:

• Teams where a developer or manager reviews content before it goes live
• Sites where content errors have a high cost (e.g., legal or compliance review required)
• Multi-author setups where you want a centralised review step

Frequently Asked Questions

Does adding Sitepins require any changes to my Astro project?

No. You don’t modify astro.config.mjs, install npm packages, change your content collection configuration, or add any files to your repository. Sitepins connects externally via your Git provider’s API and reads/writes your existing Markdown files. Your project structure is unchanged.

Can Sitepins work with Astro’s Content Collections schema defined in config.ts?

Yes. Sitepins reads your frontmatter fields and reflects them in the editing form. Fields marked required in your Zod schema appear as mandatory form fields that cannot be saved empty. Fields marked optional appear but can be left blank. Sitepins does not read the src/content/config.ts file directly — it infers field types from your existing content. For a more precise schema mapping, you can manually configure field types in Sitepins project settings.

What happens to my Astro site’s content if I stop using Sitepins?

Nothing. All content files remain in src/content/ in your repository, in standard Markdown and MDX format. Stopping Sitepins removes the editorial interface only. Your content, your Git history, and your deploy pipeline are entirely unaffected.

Do editors need to know Markdown or Git?

No. The visual editor covers all common formatting — headings, lists, links, images, bold, italic, code — without any Markdown syntax. Editors who prefer working in Markdown can switch to raw mode. Git is invisible to the editor entirely.

Can I use Sitepins with an Astro site deployed on Vercel?

Yes. Sitepins connects to your Git repository; Vercel connects to the same repository for deployment. They operate independently. Every Sitepins save triggers a Vercel deployment automatically via the standard GitHub push webhook — no additional configuration needed.

What if my Astro site has content outside src/content/?

If your content is in src/pages/ as plain .md files (without Content Collections), Sitepins works the same way — point it at src/pages/ or whatever subdirectory contains your content files. You can also add multiple content directories as separate sections within the same Sitepins project.

Can multiple editors work on the same Astro site?

Yes. You can invite multiple editors to a Sitepins project. Each editor has their own login. Concurrent editing on the same file is handled with a lock mechanism — if two editors open the same entry simultaneously, the second sees a notification that it’s being edited. Sitepins Pro and Team plans both support multiple editors; the Team plan additionally supports multiple projects under one account.

Is there a free plan?

Yes. Sitepins has a free tier for single-site, single-editor use. Paid plans start at $12/month (Pro) for solo developers managing multiple editors, and $49/month (Team) for teams and agencies. A 60-day free trial is available on all paid plans.

Try Sitepins free — give your Astro site a visual editor in 10 minutes.Start your free trial →​