Self-hosted elm.chat: share a deployment or an exact blocker

[shawnbure]

elm.chat self-hosted instances intentionally send no analytics back to elm.chat. That protects operator independence, but it also means deploy-button clicks cannot tell us whether the deployment worked.

If you tried the one-click Cloudflare path or the manual deployment, share only what you are comfortable making public:

• Result: deployed, stopped, or still testing
• Path: Deploy to Cloudflare or manual Wrangler deployment
• The exact step that worked or failed
• Your public instance URL, only if you want it listed
• One documentation change that would help the next operator

Start here: https://github.com/shawnbure/elm-chat#deploy-to-cloudflare
One-click path: https://elm.chat/deploy/cloudflare?source=github-discussion
Deployment issues: https://github.com/shawnbure/elm-chat/issues/new?template=bug_report.md

Please do not post secrets, Cloudflare tokens, account IDs, private hostnames, room links, invite links, messages, or participant information. A successful deployment is not a security endorsement: elm.chat is early-stage, has not completed an independent security audit, and still has unfinished message authentication and replay/duplicate protection. It is not intended for anonymous, regulated, or high-risk communication.

A short report such as Deployed from v0.1.2; the root config was detected; no public URL is enough. Failed reports are equally useful.

[shawnbure]

For an independent self-host report to be reproducible, please include this minimum evidence packet:

• the elm.chat commit SHA or release tag;
• Node, Wrangler, and operating-system versions;
• whether the Cloudflare deployment created the Worker and Durable Object migration successfully;
• whether a room could be created in one browser profile and an invite redeemed in a second profile;
• whether manual destruction and the configured timer behaved as expected;
• the exact command or screen where a failure occurred, with secrets and account identifiers removed;
• whether the optional analytics binding was omitted.

The success bar for this thread is deliberately narrow: one person outside the repository owner deploys without private assistance and documents either the working path or the first exact blocker. That would be self-host evidence, not a security audit, provider-portability proof, or a claim about suitability for sensitive or regulated conversations.

[shawnbure]

Self-hosting evidence checkpoint (September 4, 2026): GitHub’s 14-day repository traffic currently reports 42 clones / 31 unique cloners, and 7 unique referrals from selfh.st. The repository has 38 stars and 2 forks.

These are discovery signals—not verified deployments, active users, or security review. I still have zero independent deployment reports.

If you tried the self-host path, please share:

• commit SHA
• one-click or manual path
• whether the Worker + Durable Object deployed
• whether a two-browser room test completed
• the exact blocker or error, with secrets removed

A failed attempt is useful evidence too.

[shawnbure]

The self-host verification path now has a reproducible, redacted report template in the repository: deployment checklist and npm run self-host:smoke-report -- --path manual (or --path deploy-button).

If you try either path, please share the generated report here after filling in the actual result. It separates the Worker/Durable Object deployment, a two-browser invite and room test, post-destroy reconnect behavior, and review of known limitations. A failed step with the exact redacted error is just as useful as a pass. Leave the instance URL out unless you deliberately want it public; never include account IDs, tokens, room or invite links, messages, or participant details.

A report would be evidence about that tested deployment only. It would not establish an independent security audit, provider portability, or suitability for anonymous, regulated, or high-risk use. Message authentication and replay protection remain open work in #100.