Share a temporary public preview for client review

[huangdun]

What problem does this solve?

Silex has a useful local preview and a strong permanent-publishing direction through libre forges, but there is a smaller workflow between them: sending a client, teammate, or tester the current built site for short-lived review.

Today that requires publishing to a forge or downloading the static output and manually uploading it somewhere. The former introduces repository/authentication/CI setup for a disposable preview; the latter adds repeated manual steps and commonly produces a new URL for each revision. A localhost preview cannot be opened by a remote reviewer.

This is separate from the offline View the site work in #1742 and the permanent multi-forge work in #1739.

Disclosure: I maintain temp.md, the hosted third-party service suggested here. It is open source, anonymous publishing requires no temp.md account, and preview URLs are public to anyone with the link. Anonymous previews normally expire seven days after their latest publish.

Proposed solution

Add an optional Share temporary preview… publication action, preferably as a plugin if Silex's current extension points can support it:

1. Build the same static output Silex already produces for Download/publication.
2. Before uploading, clearly disclose the third-party destination, public-link access, and expiration behavior, and require explicit confirmation.
3. Upload the complete static output as one site and display Copy link and Open actions.
4. Store only the capability for that one preview locally, allowing Update preview to replace the site at the same canonical URL.
5. Provide Stop sharing to revoke the preview immediately.

The first version could deliberately support only simple static sites—the same initial scope described in #1742. Sites requiring a data-source/Eleventy build could become eligible once Silex can produce that final output locally. The action should block with a clear explanation rather than upload an incomplete site.

Safeguards:

• Never upload automatically or on save.
• Keep local preview, Download, and permanent publishing behavior unchanged.
• Upload only the selected site's generated output, not its editable source, credentials, preferences, or other projects.
• Preflight the anonymous size limit before transferring data.
• Show the exact expiration after publishing.
• Preserve the last successful preview if an update fails.
• Use the browser publish-session API, so Silex does not embed a temp.md secret or require a temp.md account.

This would be positioned as disposable client review and QA—not production hosting or a replacement for the libre forge roadmap.

Integration references:

• https://temp.md/docs/
• https://temp.md/openapi.json
• https://github.com/huangdun/tempmd

If the direction fits, I am happy to first map the smallest plugin-based integration against Silex's publication hooks and share that design here before writing code.

Alternatives considered

• Forge Pages: appropriate for durable publication, but requires authentication, a repository, and a build/deploy cycle.
• Download and upload manually: works, but repeats the exact packaging/upload/copy-link steps the integration would remove.
• Local preview: fast and private, but inaccessible to a remote reviewer.
• Core-only implementation: possible, but a plugin is preferable if it can receive the completed static bundle and contribute the publication UI.

Could this be a plugin?

Yes, this could be a plugin. That is the preferred starting point, provided the plugin API exposes the completed static output and an appropriate publication-action surface. If either hook is missing, I would propose only the smallest general-purpose extension point in core.

[lexoyo]

Thanks for this, and thank you for saying up front that you maintain temp.md. That kind of disclosure makes the discussion much easier.

On timing. This kind of integration belongs in Silex desktop, and Silex desktop is still in alpha. It is not released yet, and it has no connector system at all right now: when you publish, it only writes the files into a local folder. So there is nothing to plug a hosting service into yet. That is the reason this is too early, not the idea itself.

What an integration will look like. A hosting service is added with a "hosting connector". A connector is a small plugin. It receives the finished static files of a site, sends them where it wants, and returns the public URL. It does not modify the editor or the core. This already exists in the Node server, and server/plugins/DownloadConnector.ts is the smallest example you can read: no login, no OAuth, it just takes the files and gives back a link. Silex desktop will get an equivalent mechanism.

The plan is to use that same mechanism for services like Neocities. Issue #1516 has the list, and the rule: only services that are open source. temp.md is open source, so it fits.

It also means the work is usually small. Do you have a CLI for temp.md? If you do, a connector is often a small wrapper around it.

Where to put this. The best place is the roadmap, not an issue: https://roadmap.silex.me. That is where priorities get decided, and users vote there. Feel free to post it, but there is no obligation. The votes show if other people need the same thing

[huangdun]

Thanks, this is very helpful. The desktop timing and the connector boundary are clear now.

Yes, temp.md has an official CLI: tempmd-cli.

npx tempmd-cli push ./dist --json
npx tempmd-cli update ./dist --json

Anonymous publishing does not require a temp.md account. The CLI keeps the scoped update capability locally so subsequent publishes update the same URL, and it supports resumable uploads and preflight validation.

For a Silex connector, the supported ESM API exported by the same package may be cleaner than spawning the CLI. A connector could adapt the incoming ConnectorFile[] to a publish session directly, return the canonical URL, and store only the per-site update capability in protected desktop application data for update and revoke. That avoids writing the completed site to a temporary folder just to invoke a child process.

This maps closely to HostingConnector and DownloadConnector.ts, so I agree there is no reason to change the editor or core ahead of the desktop connector API. I will use the roadmap for prioritization as suggested and revisit the implementation once that connector mechanism is available.

Thanks for pointing me to #1516 and the example connector.