Grav

Last reviewed Aug 26, 2026 · 890 words

Your entire Grav site, including the content, theme, plugins, users, and configuration, is one directory that you can back up with tar and restore by extracting it onto any host with PHP. No database dump, no import wizard, no version-matched SQL. That property is the whole argument for a flat-file CMS, and Grav is the most complete one under a permissive licence: MIT, 15,651 stars, maintained since 2014, and running in about 256 MB of RAM. It is what I would hand someone who wants WordPress-style editing without WordPress-style maintenance.

Pages are folders, content is Markdown

The mental model takes 5 minutes. Under user/pages/ every folder is a page, and the Markdown file inside it names the template: 01.home/default.md renders with the theme's default.html.twig, 02.blog/blog.md with blog.html.twig, and child folders become child pages. The numeric prefix sets menu order and the file starts with YAML front matter for the title, date, and taxonomy:

---
title: Why I moved off WordPress
date: 2026-08-10
taxonomy:
  category: [blog]
  tag: [cms, php]
---
The body is plain Markdown. Images dropped into this folder
can be referenced as ![](cover.jpg) and Grav resizes them on demand.

Because it is a directory of text, the site lives in git naturally. The Git Sync plugin pushes and pulls changes on save, so editing in the browser on the server and editing in a text editor on a laptop converge on the same repository. That is also your disaster recovery.

Install takes one command, the GUI is a plugin

Grav ships as a zip; the "Grav + Admin" bundle from the download page includes the admin panel. Extract it into the web root of any PHP 8 host with the gd, curl, zip, dom, and mbstring extensions and load the URL. The Admin plugin then walks you through creating the first user. Everything else installs from the command line:

bin/gpm install admin
bin/gpm install git-sync
bin/gpm selfupgrade
bin/gpm update

There is no official Docker image, but the community images work and follow the same layout; mount user/ and you have the site. Put Caddy or nginx in front with PHP-FPM; the repository includes sample rewrite rules for both.

It is fast because of the cache, so keep the cache

A flat-file CMS still renders through PHP on request, and with no cache Grav is noticeably slower than a static site. With its file cache enabled (the default) and APCu available it serves a page in tens of milliseconds, and most of that is Twig. Two settings do the work in user/config/system.yaml: cache.enabled: true and cache.driver: auto, which picks APCu when the extension is present. Enable twig.cache too and leave it on in production; turn it off only while building a theme. The catalogue's "less ideal for very large sites" is about this layer: thousands of pages mean Grav scans a large tree on cache refresh, and above a few thousand pages the pauses after edits become annoying. Under 1,000 pages you will never notice.

The Admin plugin is a login form on the internet

The panel lives at /admin and it is the one part of the stack that is attack surface. Grav's login has rate limiting and 2FA (TOTP) built in; turn 2FA on for every account. Better still, restrict /admin at the reverse proxy to your VPN or LAN, or a basic-auth layer on top, and leave the public site unauthenticated. The site itself has no writable endpoints without the plugin, so if you do all editing through git you can skip installing Admin entirely and remove the surface altogether. Keep bin/gpm update on a monthly reminder; plugins are third-party PHP and that is where past vulnerabilities have been.

Where Hugo wins and where it does not

If you write in a text editor anyway and want zero server-side code, Hugo generates a static site that any web server or CDN hosts for nothing and cannot be hacked through a form. Grav's advantages are in-browser editing for non-technical contributors, on-demand image resizing, forms with the Form plugin, user login, and site search without a build step. Kirby plays the same game with a nicer panel and a paid licence. WordPress wins only when you need its plugin economy (e-commerce, membership, a specific page builder); for a blog, a documentation site, or a 20-page business site it is more software than the job requires, which is the argument made in my Squarespace alternatives notes as well.

What I'd do

Grav plus Admin, extracted onto a small PHP 8 host or in a community container, APCu enabled, /admin reachable only over the VPN with 2FA on. Git Sync to a private repository so the backup is automatic and a rebuild is git clone. The Quark default theme is fine to start; swap it when you have content, not before. For a site under 1,000 pages with at least one contributor who wants a browser editor, that setup has the lowest maintenance of anything in the CMS category I have run.