An HTML codes generator where the backend is already wired before the first line of HTML gets written.

What every other page on this topic leaves out

Open the pages you reach by typing this guide's title into a search bar. You get snippet catalogs (hero, navbar, card, form, table), block libraries, and one-shot generators that emit a single self-contained HTML file. All useful if the job is a static landing-page mockup. All useless the moment the generated HTML needs to save data, send email, or be shared as a real URL.

None of them mention that the generator they are describing provisions a live database, a transactional email key, an analytics project, or a git remote for you. Because none of them do. mk0r does all four on every session boot. The next sections walk through exactly where that happens in the source.

The four services, named and scoped per session

Each service gets its own resource under the mk0r umbrella account, named from the session key. Nothing is shared across sessions except the PostHog ingestion project, which uses a group property for isolation instead of a new project per app.

The orchestrator, in order

PostHog runs synchronously first (no API call, just a project key plus a generated app ID). Resend, Neon, and GitHub run in parallel via Promise.allSettled, so a failure in one does not block the other two. The wall-clock of the whole call is whichever remote is slowest on the day, not the sum.

The deliberate choice of allSettled over Promise.all is the interesting bit. An HTML codes generator that aborts the whole session because GitHub rate-limited the repo create is a bad experience. The orchestrator catches each rejection, logs it, and pushes forward with whatever did land. If your session has DATABASE_URL but no RESEND_API_KEY, the agent still writes HTML that persists data; it just skips the email path.

Inputs, hub, outputs

A session key goes in, four provisioning calls run against their respective APIs, and a bundle of env vars falls out the other side. Those env vars are what the agent sees when it opens /app/.env on its first tool call.

Naming the resources so they stay isolated

There is no multi-tenancy trick here. Every per-app resource is given a unique name derived from the session key by this three-line helper. Two different sessions cannot collide on a resource name because the session keys differ.

The twelve-character slug becomes the Neon project name, the Resend audience name (suffixed " Users"), the Resend API key name, the GitHub repo name, and the PostHog group ID. A single grep of mk0r-<slug> across four provider dashboards tells you which resources belong to which session.

What the env file actually looks like

After the orchestrator finishes, the envVars record is flattened by buildEnvFileContent into a newline-delimited .env and written into the VM at /app/.env. Here are the exact keys the code sets, grouped by service.

Twelve vars when everything lands. Fewer when a service rejected. Note the Vite convention: the PostHog keys are prefixed VITE_ so they get exposed to client-side code via import.meta.env. The Neon and Resend keys are server-side only, so they are read as process.env inside a Node script or a build-time route.

How the agent learns these exist

Provisioning the vars is half the trick. The other half is telling the generator to check for them before asking you for API keys or trying to sign up for a free-tier Postgres. That instruction lives verbatim at step 2 of the Workflow block in the VM's global CLAUDE.md.

That single bold line shifts the agent's default behavior. Ask for "a signup form that stores submissions in a database" and the agent, instead of asking you to connect a Supabase project, opens /app/.env, sees DATABASE_URL, installs @neondatabase/serverless, and writes the Drizzle schema. The HTML code that came out is actually wired up.

Watch the provisioning happen in the server log

Every step emits a structured log line via the plog helper. Here is a compressed trace of a single session boot on a good day, reassembled from the events the orchestrator emits.

What the agent does with those vars

The backend-services skill at /root/.claude/skills/backend-services/SKILL.md teaches the agent how to wire each service into a Vite project. Here is the shape of a typical turn, taken from the skill's integration patterns.

How this compares with what else comes up on this topic

No tool wins on every axis. Snippet catalogs are faster if you just need a navbar to paste into an existing site. Visual builders beat a chat UI if you want to drag a hero around. But if the question is "what happens when the generated HTML needs a backend," the comparison is stark.

What gets wired, at a glance

The usual list of "things a code generator can emit" is fine. The more useful list is "things a generator can emit that will actually function without any extra work from you".

By the numbers

The thing that makes this work without a signup is counted, not claimed. Here are the exact integers.

When this is overbuilt

If all you need is a snippet for an email signature or a static table to paste into a CMS, the provisioning pipeline is doing nothing useful for you. Use a snippet catalog and move on. The whole point of wiring Neon, Resend, PostHog, and GitHub on boot is that the moment a prompt says "save," "send," "track," or "share," the agent can just do it without asking you for anything.

A useful rule of thumb: if the HTML has a form or a button that should do something, this tool is designed for that. If it is purely decorative, almost anything will generate it.