Planned, in the open

Roadmap

Q: Will my site break after an update?

No. Each site names the HERON versions it accepts in site.yaml , and the stable version keeps building older sites. Features are removed only on purpose and after a clear warning.

Q: How do I follow progress?

Read the news and the changelog .

What HERON connects as optional modules, and what we plan to add next, in the open. Planned items have no dates: an item is ready when it works on live sites and is written into the documentation.

One rule holds for every item: the stable version keeps building the sites that exist today. A new feature is something a site switches on, never something that changes a site behind its back.

Database module

A database connects to a HERON site through an optional module. It is not part of the default build: a site that does not need live data carries nothing extra, and a site that does gets it without giving up ready pages.

Connection in site.yaml

The database is named in the same settings file as everything else, together with the private key the site uses to reach it. The key is kept outside the site folder and out of git.

Read and send only

The page reads data, such as prices, schedules or stock, or sends a request, such as a booking or a form. It cannot change the structure of the database.

Live parts of a page

Only the live block updates without a reload; the rest of the page is still a ready file and opens as fast as before.

Nothing to inject

The built container holds only ready pages and nginx. There is no program inside that an attacker could feed code to in order to reach the database.

Your database

It runs where you choose, next to the site or elsewhere, and the module talks to it over the private key.

Planned

Forms without a server of your own

A small companion service that receives forms from a static page and sends them on: to email, a CRM or Telegram. It keeps no data itself.

Described in site.yaml: Fields of each form and where its requests go.
Spam protection: A hidden field, a minimum time to fill in, a limit per address; a captcha only if you switch it on.
Why it is needed: A static page has nothing on the server to receive a form. Today you use a form service or your own script; this makes it one setting.
Example: A booking form on a clinic site sends the request to the clinic's email and to a Telegram chat at the same time.
Your data stays yours: Requests pass through and are not stored by the service.

Skills for AI agents

More ready skills on skills.sh for Claude Code, Codex and other agents: one skill per role and per common task, like moving a WordPress site or adding a language.

Same rules: Every skill follows the open contract and the role guides in the repository.
Example tasks: «Move my WordPress site», «add German to the site», «write a service page from this text».
Safe by design: Each skill says which folders it may write to; a content skill never edits the theme.
Install once: One command adds the skills to your agent; they update with HERON.

HERON for AI

A richer configurator

More questions and more kinds of organizations in the schema.org questionnaire, so the markup of a clinic, a law firm or a shop is filled from plain answers.

Grows with the site: Each new HERON feature gets its place in the configurator, with a hint and, where it helps, a short video.
Example: You choose «Dentist» and answer about address, opening hours and phone; the markup for search engines is filled from these answers.
Consistent everywhere: The same answers feed schema.org, the sitemap and llms.txt, so they never contradict each other.
No code: Every answer lands in site.yaml; you can still edit the file by hand.

Configurator

Comparisons

Honest pages that compare HERON with Hugo, Jekyll, WordPress, Joomla and other systems: what each does better and when to choose which.

Written after the feature list settles: So that every claim can be checked.
Honest by rule: Each comparison says where the other system is better, for example Hugo builds huge sites faster and WordPress has a visual editor.
Checkable: Every claim links to documentation or a measurement you can repeat.
Who it helps: People choosing a tool, and people moving from another system who need a translation of familiar ideas.

Settings for Yandex

Yandex Metrica next to Google Analytics, Webmaster verification and the regional details Yandex reads, all from site.yaml.

Same principle: One place for the setting, the build writes the rest.
What you fill in: The counter number and the verification code, once, in site.yaml.
What the build writes: The counter on every page (only after the visitor allows analytics) and the verification tag.
Region: The address and region of the organization are taken from the same company details as the rest of the markup.

How the plan is made

The plan grows from the sites built on HERON and from this site itself: every page here is checked against what HERON does, and each difference becomes a task. When a task is done, its description in the documentation changes in the same commit.

Have a need that is not on the list? First read what HERON can already do, then describe the task in the repository.

Questions

Will HERON become a CMS with a database, like WordPress?

No. Files stay the only source of your content and settings. The database module adds live parts for sites that need them; the pages themselves are still built from files.

Will my site break after an update?

No. Each site names the HERON versions it accepts in site.yaml, and the stable version keeps building older sites. Features are removed only on purpose and after a clear warning.

How do I follow progress?

Read the news and the changelog.