A visual editor for Hugo layouts, not just front matter

CloudCannon, TinaCMS and Decap edit content. They give an author a form over front matter and Markdown, which is genuinely useful and not what this is. PortBay edits the template: the element you click in the browser is located in layouts/, and the bytes that change are in your own .html file, in your repo, in your next commit. If your problem is that a marketing colleague needs to write posts, a content CMS is the better answer. If your problem is that changing the masthead means a build-refresh-squint loop, this is.

By a hugo.toml, hugo.yaml or hugo.json at the project root, or by the presence of an archetypes/ directory, which is specific enough to Hugo to be a reliable marker on its own. It is stat checks rather than a directory walk, so it costs nothing on a large site. The same helper is what tells PortBay to skip your generated public/ directory when writing, so the two can never disagree about what counts as a Hugo project.

Anything that came out of a Go template expression. Text inside {{ }} is computed at render time and is not present in the layout file as words, so PortBay refuses that edit instead of rewriting your expression into a string literal — which would silently break the page for every other route that uses the same layout. Static markup in your layouts, partials and content files is what edits, and that covers most of what you actually want to nudge visually.

Into the front matter of that route's own content file — content/about.md for /about/, resolved from the route rather than guessed. Not into baseof.html, because a title written there would apply to every page on the site, and not into the rendered HTML, because that lives in the generated output directory and would be erased by the next build. One caveat specific to Hugo: its singular image key has no reader, so that one field is refused rather than written.

Yes. The markup is stored under that page's own portbay_head_code and portbay_body_code front-matter keys, and PortBay installs a small render hook in the project once so the base template prints them into the real head and before the closing body tag. It is per-page rather than site-wide, and it is stored in your content file, so it survives in git like everything else here.

Never. Build output directories are excluded on purpose — public/ for Hugo, along with dist, build, out and the rest — because a change written there looks like it worked and disappears on the next build. PortBay treats that as fake persistence and refuses rather than producing an edit you would only discover was lost later.

No. It is a PortBay Pro feature, still in early access behind an opt-in toggle in Settings, and it is not compiled into the open-source build. It refuses to run while the site is shared over a public tunnel, and the edit bar works only on local .test hosts. Serving your Hugo site on a real .test domain with trusted HTTPS is in the free app.