Demo mode for a public demo.runicgateway.com deployment #222

New Issue

wtclaude · 2026-10-23T03:37:56-05:00

wtclaude commented

2026-10-23 03:37:56 -05:00

Why

The Android app is going to Google Play (docs/android/PLAN.md M8). The app does nothing until it is pointed at a working HTTPS Runic Gateway site and signed in, so two groups need a public site they can use:

Google's reviewers. The Play Console's Sign-in details declaration needs a URL and a working account.
The closed-test testers. Before production, a personal Play account needs 12 testers opted in for 14 days in a row. runicgateway.com /beta recruits them (its D27 already says the beta waits for a demo deployment).

The org lead decided on 2026-10-23 to run that site at demo.runicgateway.com: a separate deployment hooked to the Oxide Rust rig, so people can try the platform with a real game behind it.

What the demo needs (org lead, 2026-10-23)

Demo accounts. Ready-made sign-ins (at least player, moderator and admin, plus one for Google's reviewer) that anyone can use. They are published, so they are not secrets.
No breaking changes. A public admin account must not be able to break the site for the next visitor. That includes unlinking the sidecar, changing the setup and sidecar credentials or the demo accounts' passwords, and anything else that would stop other people using it.
A periodic wipe. The site is wiped and redeployed every couple of hours. The base stays: the Rust module, the sidecar link, the demo accounts and the seeded content come back each time. What visitors changed does not.

To decide before building

How "demo mode" is switched on: an env flag on the deployment, read by core (and modules?), so the normal image runs as the demo.
The complete list of actions to lock, and whether a locked action answers 403 with a "disabled on the demo" message the web UI and the app can show.
Whether the wipe is a DB reset to a seed snapshot (cron or a CI schedule) or a full container redeploy, and how the sidecar link survives it.
Outbound effects: email, push, Discord, and module actions that reach the game server (console-command steps, permission writes, RunicNPC). What should a public admin be able to do to the rig?
Where the demo's deployment config lives, so it can be rebuilt from scratch.

This issue only scopes the work. Design it, and get the org lead's approval, before writing any code.

🤖 Generated with Claude Code

https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

## Why The Android app is going to Google Play (`docs/android/PLAN.md` M8). The app does nothing until it is pointed at a working **HTTPS** Runic Gateway site and signed in, so two groups need a public site they can use: - **Google's reviewers.** The Play Console's *Sign-in details* declaration needs a URL and a working account. - **The closed-test testers.** Before production, a personal Play account needs 12 testers opted in for 14 days in a row. runicgateway.com `/beta` recruits them (its D27 already says the beta waits for a demo deployment). The org lead decided on 2026-10-23 to run that site at **`demo.runicgateway.com`**: a separate deployment hooked to the **Oxide Rust rig**, so people can try the platform with a real game behind it. ## What the demo needs (org lead, 2026-10-23) 1. **Demo accounts.** Ready-made sign-ins (at least player, moderator and admin, plus one for Google's reviewer) that anyone can use. They are published, so they are not secrets. 2. **No breaking changes.** A public admin account must not be able to break the site for the next visitor. That includes unlinking the sidecar, changing the setup and sidecar credentials or the demo accounts' passwords, and anything else that would stop other people using it. 3. **A periodic wipe.** The site is wiped and redeployed every couple of hours. The **base stays**: the Rust module, the sidecar link, the demo accounts and the seeded content come back each time. What visitors changed does not. ## To decide before building - How "demo mode" is switched on: an env flag on the deployment, read by core (and modules?), so the normal image runs as the demo. - The complete list of actions to lock, and whether a locked action answers 403 with a "disabled on the demo" message the web UI and the app can show. - Whether the wipe is a DB reset to a seed snapshot (cron or a CI schedule) or a full container redeploy, and how the sidecar link survives it. - Outbound effects: email, push, Discord, and module actions that reach the game server (console-command steps, permission writes, RunicNPC). What should a public admin be able to do to the rig? - Where the demo's deployment config lives, so it can be rebuilt from scratch. This issue only scopes the work. Design it, and get the org lead's approval, before writing any code. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

wtclaude referenced this issue from RunicGateway/docs

2026-10-23 17:44:07 -05:00

docs(website): design demo mode for demo.runicgateway.com #377

wtclaude referenced this issue

2026-10-23 18:52:42 -05:00

feat(demo): DEMO_MODE lock, seed:demo and the demo banner (MODULE_API 1.18.0) #223

wtclaude referenced this issue

2026-10-26 03:40:03 -05:00

feat(demo): refuse an event step at save with demoRefuses (MODULE_API 1.19.0) #224

wtclaude referenced this issue from RunicGateway/Module-Rust

2026-10-26 03:40:55 -05:00

feat(demo): the public demo's module-side locks and seed hook #62