Reola - A Git-Backed CMS for People Who Already Live in Markdown

I've been a Notion fan for years, and somewhere along the way that turned into a habit of writing almost everything in markdown first. Blog posts, notes, half formed product ideas, all of it starts as plain text with a few headers and bullet points. It's fast, it's portable, and I never have to think about formatting.

The part that's never been fast is everything around the writing.

The actual problem

Every post I write ends up needing at least one photo or a short video clip, and that's where the friction starts. I drop a 30 MB screenshot or a screen recording into a folder, then I have to remember to resize it, convert it to something the web actually wants, and figure out where it's supposed to live relative to the post. None of that is hard on its own. It's just enough manual work that I'd put off writing for another day rather than deal with it.

What I actually wanted was simple. Write the post, drop in the media, and have it show up on the CDN already compressed, without a detour through an image editor or a separate compression script.

I looked at a few ways to get there. Most CMS products solve this by owning your content in their own database, which means your posts live behind someone else's API instead of in the same repo your site already deploys from. The ones that don't do that tend to assume you're comfortable hand editing files and running your own image pipeline, which puts you right back at the manual step I was trying to remove. None of it integrated cleanly with how my site is actually built, straight from a GitHub repo.

So I started building Reola.

What I'm building

Reola is a web & desktop markdown editor that publishes directly to GitHub. You write locally, drop in images and video, hit publish, and it commits straight to the repo your site already builds from. No Reola server sitting in the middle holding your content hostage.

What that looks like day to day:

• A proper editing experience over markdown, WYSIWYG when I want it, raw markdown when I don't
• Posts saved as plain files, {slug}/content.md, with frontmatter for title, date, tags, and slug
• Drafts and a local repo cache living on disk under ~/.reola, readable with or without Reola open
• Full Git history on every post, so a bad edit is just a revert, not a support ticket

The media pipeline I actually wanted

This was the whole point, so it got the most attention. Drop a full size photo or a raw video file into the editor, and Reola resizes images to sensible display sizes, converts them to WebP, and runs video through ffmpeg into a web friendly MP4 or WebM. No separate tool, no second pass to remember.

Settings are per post, quality, size level, WebP on or off, and the defaults are tuned so most uploads need zero manual work. I can drop in a forty megabyte photo straight from my phone and Reola ships the WebP version without me thinking about it again.

Git native, on purpose

The media pipeline solves the upload problem, but the bigger decision underneath Reola is where the content actually lives. Posts are markdown files in your repo, not rows in someone else's database. That means they're reviewable in a pull request, diffable like any other change, and recoverable from a git clone even if Reola itself disappeared tomorrow.

Publish pushes a commit to your configured branch through the GitHub API, and your connected CDN, Cloudflare Pages, Workers, or Vercel, builds and deploys from there the same way it already does for code. Reola sits upstream of that as the editor and the media prep step, not as new hosting infrastructure you now have to operate.

Why today specifically

I'm not the target user I had in mind when I first thought about a "blogging tool." I'm the writer side and the engineer side at the same time, which is exactly the gap Reola is trying to close. The people who'll actually use this day to day skew engineering and DevOps, people who already care about owning their content, who don't want a black box vendor between them and their words, and who'd rather review a content change in a PR than trust an opaque CMS dashboard.

That's also why the visual language splits cleanly into two layers. The warm, illustrated style you're seeing in this post is for marketing and onboarding, the part where Reola needs to feel approachable to someone who isn't going to read documentation first. The actual product UI, the editor, the Git settings, the deploy status screen, is a clean technical layer with none of that illustration in it. Mixing the two would undercut the exact thing this product is trying to earn, which is developer trust.

Where it stands right now

Early, same as everything else I ship. GitHub linking, WebP image optimization, and local file storage are working today. Deploy and domain connection through Cloudflare or Vercel, desktop packaging, and ffmpeg video compression are the active surface I'm building out in Settings right now.

Not in scope yet: multi-tenant billing, role based permissions, non-Git backends, or a hosted SaaS version. Those are natural next steps once the core loop, local draft to GitHub commit to live deploy, holds up under real use.

What's next

The honest test is whether I keep using it for my own posts, including this one. If writing and publishing to isaaclee.xyz through Reola feels better than my current habit of writing markdown and pasting it in by hand, I'll know the core loop actually works. I'll post the next update once there's a build worth clicking on.

#buildinpublic

This one's mostly a note to myself about why the media pipeline mattered enough to build a whole tool around it. If you've ever given up on writing a post because of the image resizing step, you'll probably get it.