Why a finished Astro frontend still needs an editable layer
Agency and product teams often freeze the UI in Astro: routes, components, global CSS, literal props. That is a good delivery format for developers. It is a poor editing format for a client who only needs to change a headline, a list of works, or a page body.
The usual answer is “put it in a headless CMS.” That answer often means rebuilding the layout as CMS blocks, adding a runtime, and giving editors enough freedom to break the design. The Frontmatter path is narrower: keep layout in code, expose only the fields that were already props or page data.
Why rebuilding the layout in a CMS creates drift
If the Astro Hero is one component with two props, and the CMS later models a “flexible hero” with nested blocks, you now maintain two structures. Design changes happen in Astro. Content models happen in the CMS. They diverge within a sprint.
A Grav theme that mirrors the Astro tree — one partial per component, one blueprint per editable surface — keeps a single shape. Editors fill fields. Developers still own the HTML.
Where Grav fits
Grav is useful here because it is close to the files you already ship:
- themes are Twig, not a proprietary block language;
- blueprints are YAML, so fields can match literal Astro props;
- pages are Markdown/YAML on disk, so Git and FTP deploys still work;
- the admin is optional and self-hosted — not a managed SaaS.
Grav is not a visual page builder. It will not invent a layout that does not exist in the theme. That limitation is the point.
Frontmatter pipeline: Core → Solo → Studio
- Core scans the Astro project and writes a JSON IR (routes, props, datasets). Released, MIT.
- Solo turns that IR into Twig or PHP templates plus
INTEGRATION.md. Released, $49. Solo does not generate Grav blueprints. - Studio is planned to sit on that pipeline and emit a Grav theme, blueprints and content configuration. Coming soon. Not for sale.
You can do the Grav mapping by hand today using Solo’s Twig output as a starting point. Studio is meant to remove the repetitive YAML and folder wiring, not to replace Grav itself.
Mapping table
| Astro source | Grav destination | Who owns it |
|---|---|---|
Component (Hero.astro) | Twig partial in the theme | Developer / Solo Twig adapter |
| Page layout | Grav theme layout | Developer / Solo |
| Literal props / content model | Blueprint fields | Developer now; Studio later |
| Page data | Grav page frontmatter and Markdown body | Editor after wiring |
public/ assets | Theme assets | Developer |
What Studio plans to generate
Planned, not available:
- a Grav theme folder aligned with the Solo Twig tree;
- blueprints for the literal props and page fields that Core already extracted;
- starter page content configuration so the admin has something to open;
- notes on what still must be configured in Grav (site.yaml, users, plugins).
Until that ships, treat every Grav file below as a manual example.
What remains developer-owned
- hosting, PHP version, Grav install and updates;
- users, permissions, plugins, forms, search;
- any logic that is not a template or a field;
- CSS architecture (Solo/Studio do not invent a new design system);
- compatibility of the Astro source — still a constrained Solo-compatible project.
Compatibility constraints
The same Solo contract applies: one layout per page, literal props only, global CSS, static files from public/. No client:* islands as the source of truth for the theme. Validate with solo-check if you intend to generate Twig first.
Honest coming-soon status
Studio is early-stage. Scope may evolve. This page is a map, not a changelog of generated files. There is no purchase, trial or download for Studio.
# user/blueprints/pages/home.yaml — written by a developer today
title: Home
'@extends':
type: default
context: blueprints://pages
form:
fields:
header.headline:
type: text
label: Headline
header.sub:
type: text
label: Subtitle