htmlet

The idea came from Thariq’s tweet, after which I started to play with generating a lot of one-off HTML files with Claude, which I started using as an entry point for students, quick explanation docs, or for sharing with agents. But the problem came when I needed to show them to someone: GitHub Pages is fine for the first one (tedious by the second), and sticking static files behind nginx is its own small chore every time. So I tried to create a simple system that I would enjoy using (shareable with the world in 2 clicks).

The implementation

It’s deliberately boring, goal was to deploy once and forget. FastAPI at the core, and the “database” is the filesystem: every page is just a file under a bind-mounted ./data directory. No DB, no migrations, nothing to back up except a folder.

Four endpoints do everything:

# upload, auto-named -> /html-1
curl -X POST --data-binary @page.html -H "X-API-Key: $KEY" $SRV/api/upload

# upload to a name you pick -> /landing
curl -X PUT --data-binary @page.html -H "X-API-Key: $KEY" $SRV/api/files/landing

# list and delete
curl -H "X-API-Key: $KEY" $SRV/api/files
curl -X DELETE -H "X-API-Key: $KEY" $SRV/api/files/landing

Uploading is gated by an X-API-Key header, viewing is public.

Small caveat, why the API matters

The REST surface isn’t just for curl — it’s what makes htmlet useful with agents. The same key that uploads can also list and overwrite pages, so an agent can publish an HTML report, read back what’s already hosted, and replace it on the next run. The drag-and-drop web UI is there for when I’m the one with a file, the API is there for when a model is.

Code on GitHub.




Enjoy Reading This Article?

Here are some more articles you might like to read next: