Reference

Kaliumhexacyanoferrat/genhttp-pages@v1 takes every input of actions/deploy-pages, so a workflow keeps working as it is, and answers with the same page_url.

How activation works

Activating a repository makes a lambda (or takes yours, by its editor key), gives you the link to its editor and an activation code, and remembers the repository by name. The first run that presents the code with a GitHub OIDC token of that repository binds the code to the repository's id, which outlives renames. From then on the action asks GitHub for a token of the run, and pages.genhttp.run hands it the editor key of the lambda to publish to.

• Only someone who can change the repository's workflows gets the code into a run of it, so nobody can activate a repository that is not theirs. Once used, the code is bound and gives nothing to whoever reads it in a public workflow.
• A repository with one site may drop the code after the first run. With several, each workflow keeps its code to say which site it publishes.
• The job needs permissions: id-token: write, which Pages workflows have. Runs of forks get no token.
• The browser that activated keeps the editor link, the address and the code, under "Activated in this browser" on the start page; nothing else can hand the link out again, so bookmark it to have it elsewhere.
• Editor keys are kept sealed with a key of their own, codes only as their hash. What is kept: the repository's name and id, and the lambda.
• Prefer a secret? The editor link ends with the editor key: store it as GENHTTP_KEY and pass key: ${{ secrets.GENHTTP_KEY }} instead of the activation.

Inputs

The inputs of deploy-pages

Its own inputs

Outputs

Configuring the build

actions/configure-pages keeps working while GitHub Pages is enabled for the repository. To switch Pages off, use its drop-in, which answers with the lambda's address instead, without a base path:

- id: pages
  uses: Kaliumhexacyanoferrat/genhttp-pages/configure@v1
  with:
    activation: gp-…
# ${{ steps.pages.outputs.base_url }} is https://my-site.genhttp.run

It does not rewrite the configuration of a static site generator as configure-pages does with static_site_generator; a site at the root of its address needs no base path.

How the site is served

The way GitHub Pages serves it:

• /docs/ answers with docs/index.html, and /docs sends you there.
• /about answers with about.html.
• What is not there answers with your 404.html and status 404.
• Every answer may be cached for ten minutes, is readable from any origin, and an unchanged file answers 304.
• Names with spaces, accents, no extension or many folders work as they do on GitHub.

A backend beside the site

A static site sometimes needs code on the server: a form that stores what it is sent, a counter, a proxy that keeps an API key from the browser, something live. A lambda runs it beside the site, on the same address, so the pages call it with fetch('api/…').

Ask for it

GenHTTP Lambda is built to be changed by agents. Open the lambda's editor, go to Change and say what you need: "Add an API at api/signups that stores the e-mail addresses my newsletter form posts." Its agent writes the routes, switches on a database if they need one, tries them in a draft and puts them online.

Or use your own agent - Claude Code, Codex, Cursor - through MCP, and give it the editor link:

claude mcp add --transport http genhttp https://genhttp.dev/mcp

Why a push keeps it

A push replaces the site and nothing else: resources/site/, resources/blobs/, resources/pages.json, pages/PagesSite.cs and docs/pages.md. Everything else - the routes, resources/migrations/, the documentation - stays as the agent or you left it, and the database is never touched by a deployment. docs/pages.md says so to the next agent that reads the lambda.

The routes go in front of the site in lambda.cs, which keeps serving the site last. A lambda.cs without PagesSite.Create() is replaced by the next push.

return Layout.Create()
             .Add("api", api)
             .Add(PagesSite.Create());

A form or a button that uses the API belongs to the site, so it is changed in the repository; what the agent changes in resources/site/ is gone with the next push.

Or keep it in the repository

To have the C# in the repository instead, name its folder in backend: its lambda.cs replaces the lambda's, the other files go to backend/, and its resources/ - migrations, say - become the lambda's, all replaced on every push.

This site does it: its backend activates repositories and exchanges the tokens of their runs, with a database of activations.