Back to browse
SkyBlobs – Visual editor for content files in your GitHub repo

SkyBlobs – Visual editor for content files in your GitHub repo

by Vercist·Mar 12, 2026·2 points·0 comments

AI Analysis

MidCozyShip It

Git-based CMS for JSON and YAML files when TinaCMS and Decap already exist.

Strengths
  • Live preview works with Next.js and Vite projects out of the box.
  • PR workflow keeps content changes in existing GitHub review process.
  • No deploy pipeline required, changes stay in Git natively.
Weaknesses
  • Git-based CMS category has TinaCMS, Decap CMS, and CloudCannon already.
  • Limited to JSON, YAML, and markdown with no rich media or asset management.
Target Audience

Non-technical teammates editing website content in Git repos

Similar To

TinaCMS · Decap CMS · CloudCannon

Post Description

Hello Hacker News! I'm Andreas, and I built SkyBlobs (https://skyblobs.com). It's still early but I wanted to share it now to get feedback. I built it to solve a problem I kept running into: non-technical teammates needing to change website copy that lives in JSON, YAML, or markdown files in a GitHub repo.

SkyBlobs connects to a GitHub repo, reads your content files, and gives you a clean visual editor. You edit the text, see a live preview of how it'll look on the site, and either save directly to a branch or open a pull request. The files never leave your repo.

Here's how the workflow looks in practice: I invite my collaborator to the Github repository, they sign in with GitHub, see the content files laid out in a visual UI, make their changes, and open a PR. I review it like any other code change.

*What it supports today:*

- JSON, YAML, and markdown content files - Live preview (works best with Next.js and Vite projects currently) - Save to branch or open a GitHub PR - Nested key editing for i18n/translation files

The live preview runs your actual site framework in-browser using WebContainers so you see real output, not a mock.

*What it's not:*

This is not a full headless CMS. There's no content modeling, no schemas, no editorial workflows, no role-based permissions. It's deliberately simpler than that. If your content already lives in files in a repo and you just want people to be able to edit those files without opening VS Code, that's the use case.

I'd love to hear thoughts, especially from anyone who's dealt with the "my content is in Git but my editors can't use Git" problem. What did you end up doing? And if you try it out, I'm very open to feedback on what's missing or broken.

Similar Projects