Lektor

Last reviewed Sep 13, 2026 · 791 words

Lektor is the only static site generator I know of that ships a real point-and-click admin panel, and it has been coasting on a small maintainer bench for years. Both facts matter equally. If you are the developer and someone else is the writer, Lektor solves a problem Hugo and Jekyll do not even attempt. If you are the only person touching the site, the 3,947 stars are honest about its size and you should probably pick Hugo and get on with your life.

The idea: static output, CMS-shaped editing

A Lektor project is a folder. Content lives in content/, one directory per page, each holding a contents.lr text file with named fields. Models in models/*.ini declare what fields a page type has (a blog post gets title, pub_date, body; a product page gets whatever you decide). Jinja2 templates render them. So far it is a conventional generator with unusually strict structure.

The difference is lektor server. That command runs a local dev server on port 5000 with an /admin/ route, and the admin is a proper form-based editor: the writer sees fields, not front matter, picks a date from a widget, and never touches Markdown syntax they do not want to. Every save writes back to the flat files, so the whole site still versions cleanly in git. Databags (databags/*.ini) and flow blocks (repeatable content sections a writer can add and reorder) push it further toward a real CMS than any other static tool I have used.

How a self-hoster actually runs it

Lektor is Python, installed with pipx install lektor or into a virtualenv, and it needs about 256 MB to build a mid-sized site. There is no long-running server to host; the pattern is:

lektor quickstart          # scaffold a project
lektor server              # edit at http://localhost:5000/admin/
lektor build -O ./out      # render the static site
lektor deploy production   # push it

Deploy targets are declared in the project file and support rsync over SSH, GitHub Pages and plain FTP, so lektor deploy to your own Caddy box is one line of config. For a two-person site the honest workflow is: the writer runs the dev server on their laptop, edits in the admin, commits, and CI or a git hook builds and deploys. Nobody hosts the admin panel on the internet, and you should not try; it has no authentication because it was never meant to be exposed.

What you get that Hugo does not

Three things. The admin UI, already covered. Content models with real types, so a template can rely on pub_date being a date rather than a string somebody formatted by hand. And the plugin system in ordinary Python, which is easier to extend for a Python shop than Hugo's Go templates or Jekyll's Ruby gems. Static output means the published site is as fast and as safe as any other generator's; the Core Web Vitals post applies unchanged.

What you give up

Speed of builds, community, and momentum. Hugo renders thousands of pages in seconds; Lektor is noticeably slower on large sites. Theme choice is thin, so budget for writing your own templates. Releases arrive when a volunteer has time, and the Python version matrix occasionally lags, which is the practical meaning of "less active development". Check the date of the latest release on the official site before you commit a client to it. None of that is a defect in the design; it is the cost of a good idea that never went mainstream.

Where it fits against the field

For a developer-only blog, Hugo or Jekyll, and the Hugo vs Jekyll comparison settles that pair. For a non-technical writer who needs a live server with a login, Ghost or WriteFreely are dynamic and simpler to explain. Lektor's slot is the narrow middle: static hosting is a hard requirement, and the person writing must never see a code editor. The rest of the blogging category is broader than that slot.

What I'd do

If I were building a small business site where the owner edits three pages a year and I never want a PHP process on the server, I would pick Lektor, write the models carefully up front, and hand over a one-page cheat sheet for lektor server. For anything else I would pick Hugo, because a larger community is worth more than an admin panel over a ten-year horizon. Whichever way you go, keep the content in git; that is the part Lektor gets right that dynamic CMSes make you fight for.