htmlctl / Category Page

Self-hosted static site deployment matters more now because agents can build websites directly.

Serving a static site from your own infrastructure is easy. The harder and more interesting problem is publishing what agents generate: HTML, CSS, JavaScript, metadata, and assets that should go live quickly without being forced through framework-heavy workflows designed for human application teams.

Explore htmlctl Read the source

Exact

Staging to prod promote

SSH

Direct operator control

Loopback

Clean extension boundary

The actual problem

Why many self-hosted static deployment setups still feel incomplete.

Serving files is easy

You can put a static site behind Nginx or Caddy in an afternoon. The interesting problems begin later: preview environments, release history, rollback targets, environment-specific runtime controls, and promotion without rebuild drift.

Agent ergonomics matter now too

If every website change has to be translated through a large framework, custom shell glue, and human-oriented application structure, the stack is fighting the way agents actually work. The complexity did not disappear. It just moved into unnecessary ceremony.

What htmlctl is optimizing for

Static delivery with explicit guarantees and less framework overhead.

Pinned Input

Deploy from explicit site state

Website content is applied declaratively. Git-backed workflows can still exist upstream, but the deployment step operates on explicit site state rather than “whatever was on the branch five seconds ago,” which fits agent-authored publishing much better.

Preview URLs

Test real artifacts before cutover

Preview environments let you inspect the exact built release, not an approximate rebuild. That matters when agents are generating markup, metadata, and assets quickly and you still need precise human approval.

Exact Promote

Move staging to prod byte-for-byte

Promotion copies the release artifact exactly. There is no second build step introducing drift between what you approved in staging and what production serves.

Runtime Controls

Add auth and backends per environment

Static content stays stable while environment-specific auth policies and backend prefixes can differ between staging and production. That separation is one of the most practical parts of the model.

Extensions

Keep dynamic services outside the core

When a site needs something like a newsletter, the dynamic logic can run as an extension behind a routed prefix rather than forcing the publishing core to become a general-purpose application framework.

Retention

Prune old releases without breaking rollback

Immutable release history is useful until disk pressure turns it into an operational liability. Retention keeps rollback guarantees explicit while reclaiming space safely.

The workflow

What a serious self-hosted deployment path should feel like.

1

Apply site state to staging

Render the release, materialize generated assets, and activate it under staging without touching production.

2

Verify the real artifact

Check the preview URL, metadata, release status, generated files, and any environment-specific runtime routes. This is where a deployment system proves whether it is disciplined or decorative.

3

Promote exactly what you approved

Move the artifact from staging to production byte-for-byte. Roll back by release, not by reconstruction. That is the guarantee that makes the workflow worth having.

Best fit

Who htmlctl is for

  • agents and operators publishing websites from direct asset output
  • teams that want exact staging-to-prod promotion without rebuild drift
  • sites that are mostly static, but need a few controlled dynamic capabilities
  • builders who prefer declarative state and transparent infrastructure over framework ceremony

When not to use it

Not every deployment problem should be solved this way.

  • if you want a fully managed hosted platform with zero infrastructure ownership
  • if your app is already a large dynamic web system rather than a site with controlled runtime edges
  • if your team prefers vendor abstraction over operator visibility

Next step

Go from category view to release workflow detail.

If you are evaluating self-hosted static site deployment for agent-driven publishing, the useful next step is the exact-promote page and the broader product itself: previews, exact promote, auth, backends, retention, and extensions.

Read the exact promote page Go to the htmlctl product page