The short version: if it runs in a web browser, hatch can host it. If it needs its own server running behind the scenes, it can't - but the built-in shared tools cover most of the reasons you'd want one.
Any website made of files a browser opens directly - HTML, CSS, JavaScript, images, fonts. That includes full apps built with tools like React, Vue, or Svelte, as long as you upload the built version (the finished files, not the project folder you code in). Games, dashboards, calculators, slide decks, docs - all fine.
Hatch deliberately doesn't run per-site servers - that's what keeps it instant, cheap, and hard to break. Instead of running your own, you get a shared toolkit that handles the usual reasons people reach for a backend. Add it with one line:
<script src="/_platform/hatch.js"></script>
With that you can store and read data (hatch.db), get live updates across everyone viewing (realtime), and see who's visiting (identity) - no accounts, keys, or setup.
Yes, if it's a front-end app. Run your build (npm run build or similar) and deploy the output folder it produces (often called dist, build, or out). What won't work is a framework running in server mode - if your app needs a Node server live to render pages on each request, that part won't run here.
Logins-lite and data are covered by the shared API today (hatch.db plus identity). Calling an AI model or accepting file uploads without exposing your own keys is planned but not built yet. If you need those right now, hatch isn't the right home for that piece.
Deploys are capped at 20 MB per upload for now, which is plenty for most sites - keep large videos on a proper video host and link out. There's no fixed limit on how many sites you create.
Everyone at Accedo can see every site - there are no per-site permissions yet, so keep secrets and sensitive data off. You can add a per-site password for private sharing, or hide a site from the gallery, at deploy time or any time after (see below).
Two optional controls: hidden unlists a site from the home gallery (it stays reachable by its link - not access control), and a per-site password makes visitors enter a password before they can view it.
At deploy time (web): the Deploy card has a "Hide from the gallery" checkbox and an optional password field - set either and it applies the moment the deploy finishes.
To change it later: re-deploy the same site name with the option set to turn hiding / a password on (a plain re-deploy keeps your current settings). To turn them off, use the CLI:
hatch hide <site> # unlist from the gallery hatch unhide <site> # list it again hatch lock <site> --password <pw> # require a password (min 8) hatch unlock <site> # remove the password
Web: hover your site in the gallery on the home page and click the × (you'll confirm with the passphrase). CLI: hatch delete <site>.
Deletes are recoverable for 30 days - bring a site back with hatch restore <site> or the Restore page. After 30 days it's permanent.
Rule of thumb: build it, drop the folder in, and open the link. If it shows up and works in the browser, you're done. If it needs something running on a server, check the two lists above - or just ask.