htmlctl
htmlctl is for agents shipping websites.
Generate assets fast. Preview exact artifacts. Promote without drift. Extend only when needed.
Why htmlctl
htmlctl is for agents.
Most web tooling is designed for human developers building applications inside large frameworks. htmlctl is designed for agents that are already good at producing HTML, CSS, JavaScript, and content assets directly. The job is to publish those artifacts quickly, verify the exact result, and keep runtime complexity outside the asset path.
Preview URLs
Agents can publish fast. Humans still need to review the exact artifact. Preview hosts pin that release for approval even while staging keeps moving ahead.
htmlctl preview createApply from Git
Build straight from a local or remote Git repo at a pinned commit SHA. That keeps agent-authored publishing tied to explicit source state instead of branch drift and manual framework ceremony.
htmlctl apply --from-gitStaging → Production
Push to staging first, verify what the agent actually produced, then promote that exact same artifact to prod. No rebuild step means no hidden drift between approval and go-live.
htmlctl promoteExtensions
Route optional services like newsletters through declared backend prefixes, validate compatibility before cutover, and keep dynamic behavior outside the publishing core instead of dragging the whole system toward framework complexity.
extension validate · backend addRuntime Paths & Auth
Add proxied backends and Basic Auth policies per environment for paths like /api/*, /docs/*, or /newsletter/* without forcing every website change through an application-runtime mindset.
Rollback & Retention
Every release is immutable, rollback stays instant, and retention can prune old releases plus orphaned blobs without breaking preview pins or undo targets.
rollout undo · retention runSEO by Default
Generate OG images, favicons, robots.txt, sitemap.xml, llms.txt, and website structured data as part of the release build so agents can ship complete websites, not just markup fragments.
How it works
Generate fast. Review the real artifact. Promote exactly that.
The workflow is intentionally narrow because that is the advantage. Agents generate site assets quickly, reviewers inspect the exact release, and runtime services stay outside the artifact boundary.
Build from a pinned source
Deploy from a local folder or a Git repo and optional subdirectory. The release records its provenance so agent-authored website changes stay traceable.
Review on a pinned URL
Run doctor, inspect staging, validate any extension cutover, then hand reviewers an expiring preview URL pinned to the exact release the agent produced. Add auth policies when routes should stay private.
Promote the exact artifact
Once the release is approved, promote that artifact to prod. No rebuild, no drift, and rollback is still a one-command symlink switch if you need it.
Architecture
A publishing stack for agents with explicit runtime edges.
Go binaries, SQLite desired state, immutable release artifacts, and Caddy-managed HTTPS. The point is not to recreate a large application framework. The point is to let agents publish site assets directly while previews, auth, backends, and extension cutovers stay explicit and environment-scoped.
control plane + serving path
Optional services such as the newsletter stay loopback-bound on the host and are exposed only through declared backend prefixes like /newsletter/*. That keeps the asset pipeline deterministic while still allowing same-origin dynamic flows when the website actually needs them.
Go Deeper
Follow the htmlctl cluster from the core idea into the concrete system.
The product page gives the headline. These pages show the deeper model: why the system is for agents, how preview discipline differs from generic preview deployments, why exact promotion matters, how extensions keep the core thin, how the newsletter proves the pattern on a real site, and how htmlctl compares to the platforms you already know.
Positioning
Why agent-optimized publishing should avoid framework overhead
The deeper argument for direct HTML, CSS, JavaScript, and asset publishing instead of forcing websites through human-oriented application stacks.
Read the essay →Workflow
Static preview environments without preview-to-prod drift
See where htmlctl lines up with Vercel, Netlify, and Cloudflare Pages on preview URLs, and where exact artifact promotion changes the category.
Read the preview page →Release Control
Exact staging-to-prod promote without rebuild drift
See why htmlctl treats promotion as moving the same staged artifact to production and how that differs from other deployment models.
Read the exact promote page →System Design
How extensions add dynamic behavior without bloating the core
See why optional companion services are the right answer when a site needs runtime features but the publishing model should still stay thin.
Read about extensions →Proof Case
The newsletter extension as a real same-origin runtime feature
Signup, verification, unsubscribe, campaigns, and send tracking all live outside the publishing core while the site still feels integrated.
Read the extension page →Comparison
htmlctl vs Netlify
How htmlctl’s exact artifact promotion and self-hosted model differ from Netlify’s managed build pipeline — and when each approach fits.
Read the comparison →Comparison
htmlctl vs Vercel
What changes when you own the full deployment stack instead of routing through a platform’s CDN — a direct comparison with Vercel.
Read the comparison →Engineering Note
We don’t just design for humans anymore
How automatic OG image generation, robots.txt, sitemap.xml, and favicon support shipped in htmlctl — and why discoverability should be effortless for builders.
Read the story →Built for agents publishing websites.
Run htmlservd on one Linux server and ship from a folder, CI job, or pinned Git commit. Publish exact artifacts fast, review them on preview URLs, and add dynamic behavior only where the website actually needs it.