[Feature]: Share draft sites with an expiring public preview URL

[huangdun]

Problem

Instatic currently offers two useful but different paths:

• Preview page keeps the review inside the authenticated editor.
• Publish replaces the live public site.

There is no lightweight middle step for sending a current draft to a client or teammate for review without publishing it over the production site or exposing the Instatic admin.

This is separate from production deployment requests such as #95 and #177. The goal is a disposable review URL, not another place to run Instatic or permanently host the site.

Disclosure: I maintain temp.md and would implement and support this integration. temp.md is a hosted third-party service. Its anonymous preview flow requires no temp.md account, produces a public URL, and normally expires seven days after the latest publish.

Proposed solution

Add Share temporary preview… to the existing publishing actions menu.

The smallest useful flow would be:

1. The user selects Share temporary preview… and confirms that the generated public artifact will be uploaded to temp.md.
2. Instatic renders the synchronized draft into an isolated staging directory using the existing publisher pipeline.
3. Instatic uploads only the generated HTML, CSS, runtime JavaScript, and referenced public media—not source data, the site-transfer bundle, database contents, credentials, plugin secrets, or unpublished content that is not part of the rendered site.
4. The UI shows Copy link, Open, Update, and Revoke actions plus the expiry time.
5. Update replaces the artifact behind the same URL. Revoke immediately invalidates it.

The temporary build must not call persistSitePublish, write published page versions, alter scheduled publishing, use the active/inactive production slots, or swap uploads/published/current. Existing Preview and Publish behavior should remain unchanged.

The temp.md API call and scoped update capability should stay server-side. The capability must be stored in protected server storage, never returned to browser state, telemetry, audit details, or logs. Upload failures should leave both the existing live site and any previously successful temporary preview intact.

Before uploading, Instatic should validate the anonymous limits (100 files, 10 MiB per file, 50 MiB total). The initial implementation should fail closed when the rendered draft contains server-dependent holes or other routes that cannot work as a standalone static artifact, rather than publish a partially working preview.

This is intentionally not production hosting: no custom domains, permanence promise, production deployment configuration, or replacement for Instatic's existing publisher.

Alternatives considered

• Temporarily publishing the draft to the live site and reverting it risks exposing unfinished work and changes production state.
• Downloading or copying the static artifact and uploading it manually adds several steps and produces a new URL for every revision.
• A generic deployment-provider abstraction is broader than this review workflow. If a provider interface or plugin is preferred, I am happy to implement the capability through that boundary instead of adding provider-specific logic to the publisher.

Suggested verification

• Publisher tests proving a temporary build does not mutate published DB state or the live artifact symlink.
• Bundle tests covering file selection, path safety, generated assets, media, and all size/count limits.
• Server tests against a fake temp.md endpoint for create, same-URL update, interrupted upload, expiry, and revoke.
• UI tests for disclosure, idle, uploading, ready, updating, error, expired, and revoked states.
• A regression test showing the existing Preview, immediate Publish, scheduled Publish, and live-site behavior are unchanged.

Maintainer questions

1. Does this review workflow belong in the core publishing menu, or should it be delivered as a plugin/integration?
2. Is a static-only first version acceptable if it clearly blocks drafts containing server-dependent holes?
3. Would you prefer the temporary artifact builder to be extracted as a reusable export primitive before adding the temp.md adapter?

If the direction fits, I can follow with a focused draft PR and the tests above.

Area

Publishing