use case
Internal tool hosting for the HTML utilities your agent writes.
Single-file JSON viewers, regex testers, log filterers, payload inspectors. Each one is too small for a repo but too useful to throw away. Stacktree is the host that meets that granularity without making you stand up a project.
Where should one-off HTML utilities live?
On a publish-primitive host like Stacktree. Each utility — a JSON viewer, a log filterer, a regex tester preloaded with your patterns — lives at its own private URL with replace-in-place semantics. The agent that wrote the tool can iterate on it; your teammates bookmark the URL once and pick up improvements automatically. No repo, no CI, no DNS.
The shape of work this fits
- Your agent generates a single-file tool to inspect a specific JSON shape your team uses.
- You ask the agent for "a regex tester preloaded with the patterns we use for log parsing."
- The agent writes a tiny diff viewer for two CSV files with your column conventions baked in.
- You need a calendar-diff tool that highlights working-hours conflicts only.
- The agent emits a tiny app for visualising a webhook payload, complete with your enum colours.
Why these don't fit other primitives
- A repo is too heavy — the tool is single-file, no PRs needed.
- A Vercel project is too heavy — the tool isn't a deploy.
- A Notion page kills interactivity.
- A Slack message with the .html attached is unfindable in two weeks.
- A local file isn't shareable without the receiver doing setup.
What Stacktree gives you
- One URL per tool. Shareable, bookmarkable, gated.
- Replace in place. The agent ships v2 of the regex tester; your teammates pick it up on refresh.
- Tagged by slug. Custom slugs (Pro) like
regex.yourco.comif you want a memorable address. - CSP defaults. Single-file tools often need
script src; Stacktree applies a sensible default policy.
The agent flow
You: "Write a tool that pretty-prints our webhook payloads with the enum colours we use, and publish it as a Stacktree gated to @yourco.com."
Agent:
1. wrote payload-viewer.html
2. publish_html(file: "payload-viewer.html", slug: "payloads")
→ https://payloads.stacktr.ee
3. set_email_gate(slug: "payloads", domain: "yourco.com")Frequent questions
What counts as an "internal tool" here? +
A self-contained single-file HTML utility. Examples: a JSON viewer with custom highlighting, a log filterer for your specific format, a regex tester pre-loaded with your patterns, a payload inspector for your API, a CSV-to-table converter with your schema baked in, a calendar diff tool. Each is too small for a repo but too useful to throw away.
Why a host instead of just opening the .html file locally? +
Three reasons. (1) The link is shareable — your teammate doesn't need to clone anything. (2) The agent can replace it in place when the tool gets a new feature. (3) Privacy controls (email-domain gate, password) are a tool call away rather than a "trust the file" question.
Can I bookmark them? +
That's the point. Each tool gets a stable URL. The bookmark survives every revision the agent makes via
update_site.Are these like Cloudflare Workers / Vercel functions? +
Different shape — those are dynamic backends. Stacktree hosts pure client-side HTML/JS. The "tool" runs in the viewer's browser; nothing executes on Stacktree's side beyond serving the file.
How does this compare to Glitch or CodePen? +
Glitch and CodePen are editor-first — you go there to write code interactively. Stacktree is a publish primitive — you (or your agent) write code in your editor, then publish the artifact via tool call. They don't overlap much in workflow.
Can I gate access? +
Yes. Per-link password, per-link email-domain gate, or end-to-end encryption. The same controls that apply to any other Stacktree publish.
Related guides
Sources and further reading
Give every one-off tool a private URL.
Bookmark once. The agent updates the same URL forever.
Sign up free →