Demo Mode and Demo Admin - softerfish/fyuhls GitHub Wiki

Demo Mode and Demo Admin

Demo mode is for safe walkthroughs, onboarding, and training. It lets you show the live admin interface to a designated demo account without turning that account into a normal operator.

This is most useful when you want someone to learn the layout, review workflows, or shadow day-to-day administration before you give them real production responsibility.

Best use case: training before real access

A strong way to use this feature is:

  1. create a separate administrator account for the trainee
  2. enable Demo Mode
  3. mark that account as the demo admin
  4. let them explore the dashboard, users, storage, requests, rewards, and diagnostics areas
  5. only grant or keep real operational access on your normal admin account

This gives you a safer bridge between:

  • "never seen the system before"
  • and "ready to handle the live platform"

Good examples:

  • onboarding a new admin in their first week
  • training support staff on where to find user, request, and status information
  • showing moderators how abuse and DMCA workflows are laid out
  • walking a contractor through the platform before giving them broader responsibilities
  • recording screenshots, demos, or internal training videos without exposing too much live data

What demo mode does

When demo mode is enabled and one account is marked as the demo admin, the app gives that viewer a safer, more presentation-friendly experience.

In practice, that demo-admin view is designed to be:

  • read-only for risky admin operations
  • safer for live walkthroughs
  • less likely to expose private operator data or secrets

Examples of values that are masked, redacted, or hidden in demo-admin contexts include:

  • IP addresses
  • email addresses
  • some names and identity fields
  • tokens, passwords, keys, secrets, cookies, and authorization values
  • file paths and similar infrastructure details
  • raw support/log content in places where it would reveal too much

The goal is not to fake the interface. The goal is to let someone learn the real interface while seeing less dangerous data and having fewer ways to cause production changes.

What a trainee can still learn safely

Demo mode is especially valuable because a trainee can still build real platform familiarity. They can learn:

  • where packages, users, files, requests, and rewards are managed
  • how the dashboard is organized
  • how to move between system status, support, storage, and moderation areas
  • how requests and compliance queues are laid out
  • where storage providers and configuration areas live
  • how to investigate issues before they are trusted to fix them

That makes it useful for "watch first, do later" onboarding.

What it is not

Demo mode is not:

  • a staging environment
  • a full role and permissions system
  • a replacement for backups
  • a substitute for proper admin account hygiene
  • a fake copy of production with isolated data

It is best understood as:

  • a safer presentation layer
  • plus a protected training account for guided admin walkthroughs

Best-practice setup

Use two separate admin accounts:

  • one normal full admin account for real operations
  • one dedicated demo admin account for training, walkthroughs, and screenshots

That gives you a clean split:

  • the trainee learns the system without being your production operator
  • your real admin account remains available for actual changes, exports, fixes, migrations, and incident response

Avoid using your only real admin account as the demo admin.

Recommended training flow

If you are onboarding a new admin, a good sequence is:

  1. start with the demo-admin account
  2. walk them through the dashboard, status pages, storage setup, and request workflows
  3. let them practice finding the right areas of the platform
  4. have them shadow real tasks while still in demo mode
  5. only after they understand the environment, move them to real operational access if appropriate

This is a much safer path than handing over a live full-power admin account on day one.

How to set it up

  1. Turn on Demo Mode in Config Hub > General.
  2. Go to the Users area and choose the administrator account that should act as the demo admin.
  3. Sign in as that account and check the experience yourself.
  4. Verify that the screens you care about are readable for training and safe enough for the audience.
  5. Keep a separate normal admin account for real operational work.

What to verify before using it for training

Before you hand the demo-admin account to someone else, check:

  • which values are masked on your actual install
  • which pages are still useful for training
  • whether screenshots or screen sharing are acceptable for that environment
  • that the demo account is not the same account you use for real production changes

This matters because demo mode reduces exposure, but it should still be treated as part of an overall admin-security process, not the whole process.

Good habits

  • keep demo mode for training, walkthroughs, and guided onboarding
  • use a dedicated demo admin account instead of your real operator account
  • keep 2FA, strong passwords, and normal admin hardening in place
  • verify the live demo view before sharing it externally or using it in training material
  • turn demo mode off when you no longer need the protected walkthrough experience

Short version

If you want to train a new admin before giving them real production access, this is exactly the kind of feature demo mode is for.

Use it to teach the platform first, then grant real responsibility later.

⚠️ **GitHub.com Fallback** ⚠️