What lazysite does, grouped by what you are trying to achieve. Each capability links to its 'how it works' reference for the mechanics.

Authoring & content

Write pages as plain text and let lazysite turn them into a site.

Markdown, served instantly

Drop a .md file in the docroot and it is served as a fully rendered HTML page on first request, then cached. No build step, no pipeline.

Template Toolkit variables

Pages can carry dynamic values - site config, page front matter, computed expressions, conditionals and loops - resolved at render time.

How it works: TT variables →

Reusable content includes

Inline shared Markdown partials, code files or remote fragments into a page so common content lives in one place.

How it works: Includes →

Cached remote includes

Includes can fetch remote content and cache it for a set time, so external data appears inline without a fetch on every request.

How it works: Include TTL →

Pull in remote pages

A .url file makes lazysite fetch Markdown from a remote URL (such as a GitHub raw file) and render it through the same pipeline - so docs can live with the code.

How it works: Remote pages →

Rich layout blocks (fenced divs)

Wrap content in :::named blocks that become styled containers - callouts, columns, hero sections - without leaving Markdown.

How it works: Fenced divs →

Embed media (oEmbed)

Paste a video or social URL and lazysite expands it into the proper embed automatically.

How it works: oEmbed →

List and scan pages

Generate indexes, galleries and menus by scanning a folder of pages and looping over them - with optional filtering by tag, date or path.

How it works: Page scan →

Site search

A built-in search index and results page let visitors find content without an external service.

How it works: Search →

Sitemaps & registries

Auto-maintained sitemap.xml and llms.txt registries so search engines and AI agents can discover every page.

How it works: Registries →

Dynamic pages from query parameters

Read URL query parameters in a page to vary its output - simple dynamic pages with no application code.

How it works: Query parameters →

JSON & API output

Serve a page as pure data with api mode, or as an unwrapped fragment with raw mode - the same content reused as an API.

How it works: API mode →

Custom error pages

Author your own 404 (and other status) pages as ordinary Markdown.

How it works: 404 page →

Design: layouts & themes

Structure, style and content stay in separate layers that never touch.

Layouts and themes

A layout.tt owns the HTML chrome; a theme on top supplies colours, fonts and assets; content stays in .md files. Swap any layer independently.

How it works: Layouts →

Design tokens

A theme declares its palette and type as tokens in theme.json, auto-emitted as CSS custom properties - re-skin a site by editing values, not stylesheets.

How it works: theme.json →

Per-page layout override

Any single page can opt into a different layout from front matter - a landing page or print view without affecting the rest.

How it works: Layout override →

Install & publish themes

Install layouts and themes from a catalogue, or publish your own - including pulling them from a remote source.

How it works: Theme publishing →

Multiple views

Define alternate renderings of the same content for different audiences or formats.

How it works: Views →

Dynamic & interactive

Forms, accounts and payments are built in - no plugins to bolt on.

Customisable forms, built in

Build a contact, signup or feedback form right in Markdown with the :::form syntax - it works out of the box, validates input, accepts file and image attachments, and delivers to email or a handler. Fully customisable, and no third-party service or code required.

How it works: Forms →

Authentication & access control

Protect pages or whole sections behind sign-in, with the right state revealed per visitor.

How it works: Auth →

Payments (x402)

Gate content or downloads behind a payment using the x402 protocol, built into the core.

How it works: Payment →

Navigation from a config file

The site menu is a plain nav.conf file read by the layout - edit the menu without touching templates.

How it works: nav.conf →

Web manager UI

A browser-based manager to edit content, themes, navigation and users without the command line.

How it works: Manager →

WebDAV & AI publishing

Publish over WebDAV and a control API - the path an AI agent or script uses to manage a site with no GUI in the loop.

How it works: WebDAV →

Advanced data & templating

Power-user features for data-driven pages and feeds - no plugins, no build.

JSON data files

Point json:/data/file.json at a local JSON file and it is decoded into a real data structure you can loop over in the page - FOREACH, nested loops, indexed access and .size. The comparison and feature tables on this very site are built this way.

Template Toolkit helpers

The full Template Toolkit is available in pages and layouts: string, list and hash methods (split, join, replace, sort, first, last, size, match and more), computed expressions, and FILTERs such as markdown - real data shaping with no plugin.

How it works: TT variables →

RSS & Atom feeds

Register feed.rss and feed.atom in a page's front matter and lazysite emits both, generated from a scan of your pages and kept in sync as content changes - readers and aggregators subscribe directly.

How it works: Feeds →

Remote data & JSON

Pull a live value from a remote URL with url: (a version badge, an API field), or inline remote Markdown and feeds with includes - external data rendered through the same pipeline and cached for a chosen time.

How it works: Remote pages →

Operate & maintain

Files on disk, fast by default, and trivial to back up or move.

No database

Files are the source of truth. Nothing to provision, dump or migrate - back up by copying the folder.

Tiny footprint, low cost

One small CGI script plus a few Perl modules - no database, no application server, no build pipeline. The minimal infrastructure runs on almost anything and costs very little to host.

Self-contained, no external services

The engine runs entirely on your own server - just Perl and a web server - with no embedded AI and no dependency on any third-party or cloud service to operate. Nothing phones home, and nothing breaks when an outside API changes its terms or disappears. AI publishing is optional and uses an assistant you choose and control, not a service baked in.

Fast by default

Dynamic only on the first request; plain cached HTML is served after that, with fine-grained control over caching.

How it works: Cache management →

Static export

Run in generation mode to produce a fully static site you can host anywhere - the same content, no server process.

How it works: Build static →

Local dev server

A built-in server renders any Markdown tree locally with live preview - no install needed to start.

How it works: Dev server →

Link auditing

Scan the site for broken internal links before you publish.

How it works: Link audit →

Configuration in one file

Site-wide settings live in a single lazysite.conf, with overrides where you need them.

How it works: lazysite.conf →

Version-control ready

Everything is a file, so the whole site - content, layout and theme - lives in a git repository.

Access, permissions & governance

Decide exactly who can do what, lock content down, and keep a record of every change.

Fine-grained capabilities

Per-account grants control exactly what each user or token can do - edit content, manage themes or layouts, change config, create sub-users - checked once, server-side, across every surface.

How it works: Auth →

Per-file access control

Map any path to an owner with read and write lists (users or groups). Access only ever narrows, the owner is always allowed, and the same check binds the manager, WebDAV and the AI connector.

File locking

Lock a file so no one else can alter it. One lock store is shared across the manager and WebDAV, so a save anywhere respects a live lock.

Account & token expiry

Accounts and machine tokens can carry an expiry, after which access fails closed - useful for time-boxed contributors and partners.

Sub-users & delegation

A partner can mint scoped sub-accounts; onward delegation requires holding the capability itself, so nobody can grant more authority than they have.

Audit trail

An append-only log records who changed what, to what, when, from where, and the outcome - material changes only, never browsing.

Two-factor authentication

Optional TOTP second factor with recovery codes, self-contained with no external dependency.

How it works: Auth →

Protected internals

Scripts, secrets and credential files can never be read or written through the content tools - a hard deny-list, enforced on reads as well as writes.

AI & automation

Built for a human/AI partnership - agents publish through the same rules a person does.

AI publishing over WebDAV & API

An agent or script edits content over WebDAV and a JSON control API - no GUI in the loop - bound by exactly the same capabilities and ACLs as any human author.

How it works: WebDAV →

Analytics-driven improvement loops

An AI agent can read the site's own visitor analytics - aggregated and IP-anonymised, with real people separated from bots and crawlers - to see which content actually engages, then act on it: sharpen the copy, reorder or add pages, retune the layout or theme, and measure again. A continuous analyse-and-improve loop, run through the same publishing rules and permissions a person uses.

MCP AI connector

A built-in connector speaks the Model Context Protocol, so assistants such as Claude can manage a site through first-class tools.

How it works: AI connector →

OAuth for AI partners

Web-based AI connectors authenticate via a minimal OAuth 2.1 server with PKCE - the person proves they may act as a partner, and no secret is ever typed into the third party.

One enforced core

Every door - browser, API, WebDAV, MCP - translates to the same shared handlers, so a lock, an ACL or a capability holds identically whoever knocks.

Beyond the capabilities above, see how lazysite is engineered - the testing, security and quality practices behind them.