A URL your pipeline can produce on its own.
A lot of what an ops team generates is already static HTML by the time anyone reads it: a coverage report, a status page, the output of a docs generator, the preview of a branch. Each one needs an address, and none of them justifies a server to hand it out.
Where ops teams reach for this
The page that has to be up when everything else is down
A status page hosted on the infrastructure it reports on isn't a status page. This one is served from Cloudflare's edge, independent of whatever you run.
Per-branch previews from CI
The GitHub Action deploys the build output on every push, so each branch gets its own address and a reviewer clicks a link instead of checking the branch out.
Reports nobody wants to host
Coverage output, a benchmark run, an audit dump, a generated schema. Push the folder, share the link, delete the site when the ticket closes.
From a folder to a link
- 01
Issue an API key
One key from the dashboard does everything the dashboard does: list sites, create them, replace their files, read form submissions, delete them. Revoking it stops everything using it immediately.
- 02
Wire it into the pipeline
The GitHub Action takes a directory and the key. Outside GitHub Actions it's a multipart POST — the OpenAPI contract is published, so a client can generate itself rather than be written.
- 03
Deploy to a fixed address
Replacing an existing site swaps its contents without changing its URL, so a bookmark or a monitor pointed at build-status.harvis.page survives every run.
Pick how you drive it
All of these publish the same way and produce the same site. The only difference is what you already have open.
- GitHub ActionA step in the workflow you already have — point it at a directory and a key and it's done.
- HTTP APIMultipart POST with a published OpenAPI contract, so there's no SDK to adopt and nothing to keep in sync.
- Command lineThe same deploy from a shell script, a cron job, or your own machine when you're testing the pipeline by hand.
Put something online and see
The first deploy needs no account: drop a folder in and a live URL comes back, along with a private claim link if you decide to keep the site.
Put a site onlineQuestions from ops teams
Can I deploy from CI with no interactive step?
Yes — that's what the API key is for. Neither the GitHub Action nor the HTTP API needs a browser or an interactive login anywhere in the deploy path.
Does harvis run anything server-side — a health check, a cron, a proxy?
No. It serves the files you upload and collects submissions from forms on them; there's no runtime behind that. A status page here is a page your pipeline regenerates and redeploys, not one that polls anything by itself.
What are the per-site limits?
500 files and 50 MB per site. A generated report, a docs build, or a status page sits well inside that; a build carrying a few hundred megabytes of binary assets isn't the shape this is for.
Do I need an account?
Not for the first deploy. You get a live URL and a private claim link; the claim link attaches the site to a free account when you want to choose its subdomain, redeploy over it, or delete it.
What can harvis not host?
Anything that needs code running on a server: PHP, Node, Python, a database, or a page rendered at request time. harvis serves the static files you upload and collects submissions from forms on them. A JavaScript front end talking to an API hosted elsewhere works normally.
What does it cost?
Publishing is free — 500 files and 50 MB per site, no card, and sites that do not expire. If a month outgrows the free limits the account steps onto the nearest paid step, from $5, and steps back down when usage does. Bandwidth and SSL are never billed.
Is someone else's job closer to yours?
The product underneath is the same — these pages just start from a different problem.