Skip to content

Settings

The Settings page is organised into tabs across the top and a section sidebar on the left. There is always a General tab, plus one tab per enabled module — Flights, Cruises and Lodging — so domain-specific options only appear when you use that domain.

Everything auto-saves as you change it where auto-save exists: a small “saved” strip at the bottom says so. Sections that need a confirmation — a security change, an import — have their own button.

Most settings are per-user (your own account). Instance-wide settings live in the separate admin panel, reachable from the top navigation for users with isAdmin: true — see the admin panel reference. Admin is a peer of Settings, not a section of it.

  • Username, first and last name, contact info, profile picture — edit your account details and upload an avatar. The name is shown in the account menu.
  • Change password — current password + new password (8+ characters).
  • Force password change on next login — used by admins when they reset another user’s password without seeing it.
  • Language — German (default) or English. Lives in your profile and follows you across browsers when you sign in elsewhere.
  • Timezone and date / time formats — controlled centrally here.
  • Theme — the app is dark by default.
  • Domain colours (beta) — on an instance with the beta switch on, each domain’s colour can be chosen rather than taken from the brand. It applies to statistics, the trip timeline, the activity rail and the import log. With the switch off everyone gets the brand set.

Enable or disable the travel modules (“domains”). Flights, Cruises and Hotels (lodging) can be toggled by every user. Places appears here only on an instance whose administrator has turned on the beta switch.

Enabled modules show up in navigation, dashboards, the map, achievements and statistics. Disabling a module only hides it — your data is preserved and comes back when you re-enable it. Disabling a module also removes its tab from this Settings page.

Kilometres / miles, °C / °F, 12 h / 24 h — and the currency. There is exactly one currency setting since 2.6.0, and it applies everywhere: flights, cruises, lodging, statistics and achievements. (Earlier versions had a second one under the lodging preferences; the two were merged.) Conversions already recorded keep the rate they were taken at. The distance unit also governs cruise distances. See Money & currencies.

Per-user email reminders before upcoming flights. Default: off — you have to opt in.

  • Notification email — a separate address for reminder mails. Empty = reminders go to your account email.
  • 24 h reminder — a mail roughly 24 h before the next flight’s departure time (timezone-aware, resolved against the departure airport’s IANA timezone).
  • 2 h reminder — a mail roughly 2 h before departure.

Reminders are best-effort: they depend on SMTP being configured by the admin, and a provider outage during the reminder window simply drops that reminder. Don’t rely on them for anything that must arrive on time.

Two things sit here because both answer “get my data out”, though they are not the same thing:

  • Export all data — your account as JSON, twelve domains, for moving to another instance. It does not carry stored API keys.
  • Spreadsheet — the whole logbook as one workbook, a sheet per table, for reading and editing. Comes back through Import. See Spreadsheet.

The instance-wide backup schedule (cron, retention, WebDAV) is an admin setting and is shown here read-only for non-admins.

The import hub: one tile per enabled domain for list imports — flight logbooks (Flightradar24 or any CSV), a hotel CSV, the spreadsheet round trip, and on beta instances a Google Maps saved-places list. Below the tiles sits the import log: every run as one batch, with what it created, and a button to revert the whole batch. A switch decides whether flights sharing a booking reference silently become a trip. Single documents — a mail, a PDF, a photo — are not imported here but through each domain’s own add dialog. Details on Import & Export.

Per-user connections to services that belong to you rather than to the instance: an Immich server for photo albums, and — on beta instances — a Dawarich location-history server. Each has a test button. A connection the administrator configured instance-wide is used when you have none of your own.

Pair the TravStats Companion app with your account by scanning a claim code. The section is offered only on an instance with the beta switch on; the app itself is in testing and has no store listing. The flow, its security properties and what the app reads are on Companion app.

Personal Access Tokens (PATs) for AI agents, scripts and external tools.

  • Create — name + scope (read, write, admin) + optional expiry. The plaintext token is shown once on creation.
  • Format — ts_pat_ followed by a 64-character hex suffix. Stored as a bcrypt hash plus an indexed lookup hash; the plaintext never touches disk.
  • Use — Authorization: Bearer ts_pat_… on any authenticated endpoint.
  • Scopes — read blocks all mutations, write covers normal CRUD, admin is required for every /admin/* endpoint even if your account has isAdmin: true.
  • Revoke — instant.

Token management is a browser-only surface: a PAT cannot list, create or revoke tokens. Full page: Personal Access Tokens.

Two-factor authentication (TOTP with single-use recovery codes) and passkeys (which replace the password) are set up here. A locked-out user’s second factor can be reset by an administrator. The whole topic — what each one protects against, why a passkey also satisfies two-factor, what the browser needs — is on Security.

Version and build information for the running instance, and the “what’s new” notes for the release you are on.

  • Home airport — your base airport, used in statistics.
  • Default values — new flights are pre-filled with these. Seat class and category default to no default: an untouched form does not classify a flight.
  • Features — the two per-flight toggles: cost tracking and aircraft registration tracking. They moved here from the General tab in 2.6.0 because only flight surfaces read them.
  • Historical enrichment — fills in missing flight data by aggregating reference flights that share the same flight number.
  • Automatic updates — fetch current flight data from the enrichment APIs around active flights. Fetched changes land in the Inbox as proposals rather than being written straight to your log. Also moved to this tab in 2.6.0.
  • API keys — keys for the flight-data services. Keys the administrator shared instance-wide are used automatically; keys you enter here override them for your account.
  • Cruise preferences — defaults for new cruises and how they render on the map.
  • Lodging preferences — defaults for new stays (board, room type).
  • Loyalty programmes — a card is created once and covers as many chains and individual houses as it really covers; each stay derives its programme from here. See Lodging.
LayerPersisted inExample
Per-user preferencesuser_settings (Postgres)Language, units, currency, module toggles, country strictness override
App-sync prefsuser_settingsThe Companion app’s saved display preferences
API / device tokenspersonal_access_tokensHashed bcrypt + lookup hash, scope; device tokens also carry a device id and platform
Second factor / passkeyson the user row and a passkeys tableTOTP secret (encrypted), recovery codes (hashed), registered credentials
Instance settingsadmin_settingsName, registration mode, max users, beta switch, country strictness default, FX fallback switch
API keys / SMTP / Ollamaadmin_settings (encrypted)AES-encrypted with /app/data/secrets/encryption.key
Boot-time secrets/app/data/secrets/ (file system)jwt.secret, encryption.key

The only env-vars TravStats reads at runtime are DATABASE_URL, COOKIE_SECURE, CORS_ORIGIN, TZ, and OLLAMA_URL (the last only to seed the default; admins can change it from the UI). Everything else is in the database, which is what makes the data volume the only thing you need to back up.