Maurice
7da0080557
* docs(wiki): correct the install and operations pages for 4.0.0 Quick Start passed docker an empty ENCRYPTION_KEY: an assignment prefix is not expanded on the same command line, so the server silently generated its own key instead of taking the one the page told you to set. The tag examples pinned to the 3.x line, the documented tmpfs size did not match the shipped compose file, and several .env values were described as reaching the container when compose never interpolates them. * docs(wiki): match the MCP reference to the registered surface The scope table was missing the whole Collections group and the totals said 27 scopes across 13 groups where the code registers 29 across 14. The Cloudflare link on the setup page pointed at an anchor on its own page instead of the heading on Troubleshooting. * docs(wiki): correct the plugin and admin pages Three links to Plugin-Development carried a .md suffix, which does not resolve on the wiki. The admin pages described tabs, permissions and storage behaviour that had moved on. * docs(wiki): bring the feature pages back in line with the app Costs still documented the old panel, where categories could be added, renamed, reordered and deleted; they are fixed now and the panel is a day-grouped ledger with settlements. Trip sharing, journeys, maps, packing, reservations and the account pages had all drifted in the same way. * docs(wiki): cover the pages the first pass did not reach The MCP catalog listed 168 of the 201 registered tools; the settlement tools and rate_place were missing here and the Collections family from the addon page. Several resource rows claimed a trips:* scope where the handler asks for trips:read. * docs(wiki): tighten the corrections a review picked apart The audit-log resource is the row id, not the credential id; an admin password reset does not bump password_version the way the page implied; and a few of the new paragraphs described behaviour more confidently than the code supports. * docs(wiki): fix what a last read-through caught Costs shows every figure in your display currency, not the trip's, and an expense with no payer still counts against the members it is split between. Studio's cutoff is a 1024px viewport rather than phones alone, and the Integrations tab is gated on the providers an admin has configured. * docs(wiki): the last few the review caught A passkey satisfies the MFA policy everywhere except the WebSocket handshake, which still asks for TOTP, so a passkey-only account under that policy gets no live updates. Mobile optimizes a day from two places, not three. The ctx.db row carried an unescaped pipe that split the table, and the Backups table linked with a wiki link whose pipe did the same.
4.2 KiB
Demo Mode
Demo mode lets you run a public "try before you install" instance of TREK. A shared demo account is available for visitors, write operations are blocked for that account, and the database resets automatically every hour so the instance stays in a known state.
Enabling demo mode
Set DEMO_MODE=true in your environment and restart TREK. See Environment-Variables for how to set environment variables.
When demo mode is active, the login page shows a one-click "Try the demo" button. Clicking it logs the visitor in as the demo user immediately — no credentials need to be entered and no registration is required.
Demo account (auto-created on first start):
| Field | Value |
|---|---|
demo@trek.app |
|
| Password | demo12345 |
Admin account: an admin account is also seeded on first start. By default it uses username admin, email admin@trek.app, and password admin12345. You can override these at seed time with the DEMO_ADMIN_USER, DEMO_ADMIN_EMAIL, and DEMO_ADMIN_PASS environment variables (they only take effect when DEMO_MODE=true, on the first start before the database is seeded). See Environment-Variables.
What the demo user can and cannot do
The demo user account has read access to the shared trip data but the following operations are permanently blocked:
- Password change — returns 403.
- Account deletion — returns 403.
- MFA enrollment or removal — returns 403.
- File uploads — avatar uploads, trip cover uploads, and document/photo file attachments are blocked and return 403.
- All MCP write tools — create, update, and delete operations via the MCP API are blocked for the demo user.
Registration is also disabled while demo mode is active — visitors cannot create new accounts.
The admin account is unaffected and retains full access.
Hourly reset
TREK schedules an automatic hourly reset of the demo database. At each reset:
- The current
travel.dbis replaced with the saved baseline (travel-baseline.db). - The admin account's credentials (
password_hash, API keys, avatar) are re-applied on top of the restored baseline, so admin API keys and password changes survive the reset — but only whenDEMO_ADMIN_EMAILis set explicitly.
If no baseline has been saved yet, the reset is skipped and a message is logged.
The seeder defaults the admin address to admin@trek.app while the reset defaults it to admin@nomad.app, a legacy quirk that is pinned deliberately. With DEMO_ADMIN_EMAIL unset the reset looks up an address that does not exist, finds no admin row, and skips the carry-over entirely — a password change, API key or avatar set after the baseline was saved is lost on every hourly reset. Set DEMO_ADMIN_EMAIL (to admin@trek.app, for instance) if you want them to survive. Unlike the seed-time variables above, the reset reads it on every run, so setting it on an already-seeded instance and restarting is enough.
The instance-wide Maps and Unsplash keys stored in app_settings are carried across either way, so map and photo search keep working after a reset.
Saving a baseline
The baseline is the snapshot the hourly reset restores to. The admin can update it at any time:
Endpoint: POST /api/admin/save-demo-baseline
This is available in the admin panel. The baseline captures the current state of the database — including trip data, settings, and encrypted API keys — so demo features (maps, photos, weather) continue to work after each reset.
On first start with demo mode active, TREK seeds three example trips (Tokyo & Kyoto, Barcelona Long Weekend, New York City) owned by the admin and shared with the demo user, then saves the initial baseline automatically.
Limitations
- Demo mode is not for production use with real user data. The hourly reset deletes all visitor-created content.
- All demo visitors share a single account — there is no isolation between sessions.
- File uploads (photos, documents, trip covers, avatars) are disabled for the demo user.