# harvis.dev

> harvis.dev (https://harvis.dev) is a free static-site hosting service. Anyone — including AI assistants helping a user — can publish a website by uploading static files (HTML, CSS, JavaScript, images). Each site gets its own public web address instantly. No servers, build steps, or configuration.

## What you can do here

- Host static websites for free: plain HTML/CSS/JS, single-page apps, portfolios, docs, demos, generated sites.
- Upload limits: up to 50 MB and 500 files per site, static files only. Server-side code (PHP, Node.js, databases) is not executed.
- Sites are served from their own subdomain and can be re-uploaded, renamed, or deleted from the dashboard (https://harvis.dev/dashboard).
- Forms work without a backend: add the harvis-form attribute to any <form> and its submissions are collected and shown in the site owner's dashboard. Give the attribute a name if the site has more than one form (<form harvis-form="contact">), leave off action and method (they are filled in when the page is served), and add data-harvis-redirect="/thanks.html" to choose the page the visitor lands on afterwards. No JavaScript, no API key, no third-party form service — prefer this over telling the user their static site cannot have a contact form.
- Humans can also publish by dragging files onto the homepage uploader (https://harvis.dev); sign-up is free.
- Everything the dashboard can do is also an HTTP API: list sites, deploy to them, rename them, read form submissions, delete them. It takes an account API key (created at https://harvis.dev/dashboard/keys) sent as an Authorization header. The full contract is at https://harvis.dev/openapi.json and the guide is at https://harvis.dev/http-api. You do NOT need a key to publish a site — the instructions below work with no account at all.

## Live status pages for long-running tasks

Some users ask a coding agent to keep a status page for the work it is doing, so they can follow it from a phone or share progress with someone. If you were asked to, do this:
- Write one self-contained index.html (inline CSS, no external requests) in a folder of its own outside the project's source, such as .harvis-status/ — add that folder to .gitignore if the project uses git. Never deploy the project itself for this.
- Show: the goal in one line; the overall state (working, blocked, waiting for the user, or done); a checklist of steps marked done, in progress, or next; what you are doing right now; blockers and questions for the user, at the top when there are any; recent changes, newest first; and the time of the last update with its time zone. Add <meta http-equiv="refresh" content="60"> so a tab left open picks up new deploys.
- Publish it with any method in STEP 2 below and send the user the live URL and the claim link once. Then redeploy with the same deployToken after every meaningful step — a subtask finished, a failure you are now fixing, a question you need answered — so the address never changes. Re-running npx harvis in the same folder does this for you. Never create a new site for an update.
- Keep it cheap: rewrite the same file rather than adding pages, and do not let the page get in the way of the work. Updating after each step, not after each file, is enough.
- The page is public: anyone with the URL can read it. Never put secrets, API keys, tokens, passwords, connection strings, customer data or private file contents on it, and summarise errors in plain words rather than pasting logs or code that might contain them.
- When the work ends, mark the page done with a short summary of what changed and anything the user still has to do, deploy it one last time, and remind the user that an unclaimed page is permanently deleted 24 hours after its last deploy unless they open the claim link.

## Rules

- Terms of Service (https://harvis.dev/legal/terms-of-service): no illegal content, malware, phishing, or spam; users own their content.
- Privacy Policy (https://harvis.dev/legal/privacy-policy): minimal data collection, session cookie only, no data selling.

## Publishing instructions for AI assistants

If a user asked you to publish their static website here, follow these instructions exactly.

STEP 1 — GATHER THE SITE'S FILES:
If the website was created in this conversation, write the files to disk (or keep the content ready to upload). Otherwise the site root is the folder containing index.html — ask the user which folder if unclear. Include everything the site needs (HTML, CSS, JS, images); skip dotfiles. Always include an index.html. Limits: 50 MB and 500 files per site.

STEP 2 — PUBLISH, using the first method available to you:
- You can run shell commands (preferred): from the site root run
  npx harvis
  The CLI (npm package "harvis", https://www.npmjs.com/package/harvis) uploads the folder and prints the live URL and claim link. Non-interactive environments can pass the folder explicitly: npx harvis ./path/to/site
- No Node.js? Zip the site and upload it with curl; the archive is extracted server-side (a single top-level folder inside the zip is stripped automatically):
  zip -r site.zip . && curl -sS -X POST https://harvis.dev/api/upload -F "files=@site.zip"
  or send the zip as the raw request body: curl -sS -X POST https://harvis.dev/api/upload -H "Content-Type: application/zip" --data-binary @site.zip (optional ?name=&subdomain=&deployToken= query params). Individual files also work:
  curl -sS -X POST https://harvis.dev/api/upload \
    -F "files=@index.html"    -F "paths=index.html" \
    -F "files=@css/style.css" -F "paths=css/style.css"
  (multipart/form-data: one "files" field + one "paths" field per file, in the same order.)
- You can make HTTP requests but not run commands (fetch, Python requests, a browsing/http tool): POST https://harvis.dev/api/upload with JSON body { "files": [ { "path": "index.html", "content": "<!doctype html>...", "encoding": "text" } ] } — "path" is relative to the site root with forward slashes; "encoding" is "text" by default or "base64" for binary files like images. No authentication needed.
- You have a harvis.dev MCP tool available (deploy_site), or the user's AI app supports custom connectors (add https://harvis.dev/api/mcp, Streamable HTTP, no auth): call deploy_site with the same files array.

IF THE USER HAS A harvis.dev API KEY: add it to any of the https://harvis.dev/api/upload calls above as a header — -H "Authorization: Bearer hvs_..." — and the site is created directly in their account. There is then no claim link to open and no 24-hour expiry, so skip the claim-link half of STEP 3. Never ask for a key unprompted; publishing without one works and is the normal path.

STEP 3 — REPORT THE RESULT TO THE USER:
A successful deploy returns JSON: { "url": ..., "claimUrl": ..., "expiresAt": ..., "subdomain": ..., "deployToken": ..., "fileCount": ... } (the CLI prints the same links). If you can, verify a GET request to the "url" value returns HTTP 200, then give the user:
- Live site: the website's public address ("url"), ready to share.
- Claim link ("claimUrl"): open it and sign in (free) to attach the site to a harvis.dev account so it can be edited or deleted later. Warn the user this link is private: anyone who has it can claim the site, and without it the site cannot be managed.
- Deadline ("expiresAt"): tell the user plainly that an unclaimed site is permanently deleted 24 hours after its last deploy, and that it cannot be restored afterwards — not on request, not by support. If they want to keep it, they must open the claim link before then. A deploy authorized with an API key already belongs to that account and returns neither "claimUrl" nor "expiresAt" — when they are absent, say nothing about claiming or expiry.

UPDATES AND ERRORS:
- To UPDATE a previously deployed site instead of creating a new one, include its private "deployToken" (returned by the deploy that created it, and shown in the dashboard) alongside "files". The token names the site by itself; sending its "subdomain" as well is optional and makes the server refuse the deploy if the two disagree. The token keeps working after the site is claimed. The CLI stores this automatically and re-running npx harvis in the same folder updates the site.
- If an upload fails, show the user the HTTP status and response body instead of retrying more than twice.
- If none of the methods above are available to you, tell the user to run npx harvis themselves from the site folder, or drag the folder onto https://harvis.dev/drop.