DEV Community: Andrius Putna

A static site that collects form submissions, in one HTML attribute

Andrius Putna — Thu, 13 Aug 2026 12:50:05 +0000

A static site has no backend. That is the point of one — and it is also why the contact form is the first thing that breaks. The usual answers are a third-party form service with its own signup, a serverless function you now maintain, or a mailto: link nobody clicks.

There is a third option that falls out of how static hosting already works: the host is in the path of every HTML response it serves. It can collect the form itself.

On harvis.dev that is one attribute:

<form harvis-form="contact">
  <input name="email" type="email" required>
  <textarea name="message"></textarea>
  <button>Send</button>
</form>

Deploy, and submissions show up in the dashboard. No script tag, no API key in the page, no fetch(), no JavaScript at all — the form works with JS disabled, because it is a plain HTML form doing what plain HTML forms have always done.

The page I am describing is live at harvis-forms-example.harvis.dev — submit the form and see where you land. Everything below is what makes that page work.

What actually happens

The rewrite happens on the way out, while the HTML is being served:

action and method are replaced with /__harvis/form/contact on your site's own subdomain. Same origin, so there is no CORS, no preflight, and nothing in the page has to know a project id.
A honeypot field is inserted. It is positioned off-screen rather than display: none, because a bot that skips hidden inputs is a bot that would otherwise get through. Anything that fills it in gets the success page and is stored nowhere — a bot that can tell it was caught is a bot that tries again differently.
data-harvis-redirect="/thanks.html" becomes a hidden field, since the handler never sees your HTML — only what the browser posts. It is re-validated on arrival, and a protocol-relative //somewhere-else is refused.

The reply is a 303, so the browser follows it with a GET and a refresh on the thank-you page cannot post the form twice.

The form name is part of a URL and a dashboard heading, so it has to match [a-z0-9][a-z0-9_-]{0,39}. Anything else — including a bare harvis-form with no value — collects under default. Two forms on one page, two named inboxes:

<form harvis-form="contact" data-harvis-redirect="/thanks.html">…</form>
<form harvis-form="newsletter">…</form>

The second one has no redirect, so it lands on a branded thank-you page the host serves.

The one case where the attribute does nothing

The rewrite runs over the response body, so it only sees markup that is already in the file. A form that React, Vue or Svelte mounts at runtime has no <form> in the served HTML — the marker never matches and nothing is rewritten. Write the endpoint yourself instead:

<form action="/__harvis/form/contact" method="post">
  <input type="hidden" name="_harvis_redirect" value="/thanks" />
  {/* …your fields… */}
</form>

The receiving side does not care who wrote those fields. Drop the harvis-form attribute when you do this, or a prerendered page gets rewritten twice and ends up with two honeypots.

Try it

The page: https://harvis-forms-example.harvis.dev/

The complete source — two forms, the deploy script, the workflow — is here:

https://github.com/harvis-io/solutions/tree/main/forms-example

Three files of site, no build step, no dependencies. Clone it, run HARVIS_API_KEY=hvs_… ./deploy.sh public, and you have a static page with a working contact form about two seconds later.

Here is the served HTML of that live page, which is the shortest version of this whole post:

<!-- what is in the repo -->
<form harvis-form="contact" data-harvis-redirect="/thanks.html">

<!-- what the browser receives -->
<form harvis-form="contact" data-harvis-redirect="/thanks.html"
      action="/__harvis/form/contact" method="post">

npx hosting — deploy any folder to a live URL in one command, no account

Andrius Putna — Sun, 02 Aug 2026 15:31:54 +0000

I built a zero-config CLI that deploys the current folder to a live site. Anonymous by default, with a single-use claim link if you want to keep it.

Every static hosting tool I've used asks for the same ritual before you can see your site online: create an account, verify an email, install a CLI, log in, answer a config wizard. That's a lot of ceremony for "put these files on a URL".

So I built hosting — a CLI where the entire flow is:

npx hosting

That's it. No account, no config, no login. Your folder is live:

Uploading 3 files (12.4 KB)...

  Live site:   https://1freehosting.com/s/happy-panda-482
  Claim link:  https://1freehosting.com/claim/xxxxxxxx-...

The claim-link model

The interesting part isn't the upload — it's the ownership model.

Deploys are anonymous by default. You get two links back:

Live site — the public URL, share it with anyone.
Claim link — private and single-use. Open it, sign in, and the site attaches to your account so you can manage it from a dashboard.

Unclaimed sites expire 24 hours after the last deploy. That keeps throwaway experiments truly throwaway — no zombie sites, no cleanup — while anything you actually care about is one click from permanent.

This inverts the usual order: instead of authenticate, then deploy, you deploy, then decide if it was worth authenticating for.

Updating the same site

The first deploy writes a .hosting.json file with the site's deploy token. Every later hosting run from that folder updates the same site — before and after you claim it.

vim index.html
hosting        # same URL, new content

Some details I sweated:

.hosting.json is added to your .gitignore automatically (it contains the token).
Hidden files (.env, .git, …) are skipped client-side, so secrets never leave your machine. node_modules and OS junk are skipped too.
Want a fresh URL? hosting --new.
Deploying from CI or another machine? Grab the token from the dashboard and run hosting link <subdomain> --token <token> (or set HOSTING_DEPLOY_TOKEN).

Commands

Command	What it does
`hosting`	Deploy the current folder (updates the linked site, or creates one)
`hosting deploy [dir]`	Deploy a specific folder
`hosting link <subdomain>`	Link the folder to an existing site
`hosting claim`	Open the last deploy's claim link in your browser
`hosting open`	Open the last deploy's live site

Fit for AI coding agents

It's also a nice fit for AI coding agents: an agent that just generated a landing page can run one non-interactive command and hand you a live URL — no browser login dance mid-session.

Try it

cd your-static-site
npx hosting

The CLI is MIT-licensed and open source — it's the companion to 1freehosting.com, where claimed sites live.

I'd love feedback on the claim-link flow — does "anonymous first, claim later" feel right to you, or would you rather log in up front? 👇

Also thinking to create Github action for temporary or permanent artifacts preview deployments.