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 status.harvis.dev 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.
- Командний рядокThe 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.