Why Heine?

Heine began as the static-site generator I wanted for my own sites. I had used Hugo and then Zola, and eventually encountered problems that were small in isolation but expensive in attention: the development server could not serve media in a way that let browsers seek via HTTP range requests; two routes could claim one output file; localized interface text needed a clearer model; and TeX needed to be understood by the Markdown parser before it could be rendered.

The result is not an attempt to outnumber other generators' features. It is a tool with a narrower aim: turn authored content into a static site while checking the relationships that can otherwise fail late or silently.

What Heine checks

Before it writes a full output tree, Heine resolves pages, copied assets, templates, generated resources, and their routes into one site model. That makes several ordinary authoring mistakes build errors rather than files that quietly replace one another:

• pages, generated listings, taxonomies, feeds, sitemaps, and other output claims cannot share an output path;
• internal page: and asset: references name known rendered pages and copied assets;
• configured templates, collections, taxonomies, and generated resources are checked even when current content happens to leave a listing empty;
• source paths and output paths remain distinct values, so a URL-looking string is not treated as a filesystem path by accident.

This model is useful when a site gains pagination, taxonomies, translations, or several generated resources. Those features all make claims about the same output tree.

Localization without template forks

Heine treats locale-aware content, routes, and interface text as related but separate concerns. Pages have explicit locale identities and optional translation groups. Fluent resources supply localized labels and plural forms, with a configured fallback chain that is checked at each template call.

That keeps translated page relationships visible in the content model, while templates can keep using the same structural markup. It also lets a site state text direction per locale instead of assuming that every locale is left to right.

Markdown that understands math

When math is enabled, Heine enables the corresponding Markdown parsing before it interprets TeX. Inline and display math are recognized as math constructs rather than being exposed to ordinary Markdown punctuation rules. Heine can preserve TeX for a client renderer or render checked MathML during the build.

The same Markdown boundary handles checked internal links, syntax highlighting, tables, task-list labels, footnotes, margin footnotes, and native picture blocks. These are authored constructs with defined output, not template-side string rewriting.

A development server for the site you publish

heine serve is deliberately small, but it serves the generated output tree with live reload and HTTP byte-range responses. Browser media controls can therefore seek audio and video while you preview a site locally. This is a development-server convenience. Production hosting remains the web server's responsibility.

The server is not a second rendering model. It serves what the build produced. That keeps local behavior close to the published site while preserving the same checked build pipeline.

What Heine leaves out

Heine does not try to be a frontend toolchain, deployment framework, image processor, CSS compiler, or general plugin host. Dedicated tools remain better owners of those jobs.

This is a good fit when you want a static-site generator with an explicit content model, deterministic output, and diagnostics for site relationships. It may not be the right fit when an existing theme marketplace, a broad plugin ecosystem, or a framework-managed frontend pipeline is the central requirement.

Heine is pre-release software. Its scope is shaped by the sites it was built for, and its documentation describes the behavior that exists today.