* 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.9 KiB
Photo Providers
TREK can browse your personal photo library on Immich or Synology Photos and attach selected photos to trips. TREK never copies the original files — it stores only a reference (provider name + asset ID) and proxies all image streams through its own server, so your provider credentials are never sent to the browser.
Admin: Enable at least one photo provider (Immich or Synology Photos) in Admin → Addons — photo provider toggles appear as sub-items under the Journey addon. Once a provider is on, its settings card appears in each user's Settings → Integrations. If your provider runs on a local or private network, the server must be configured to allow internal network access. See Admin-Addons and Internal-Network-Access.
Supported providers
| Provider | Internal ID |
|---|---|
| Immich | immich |
| Synology Photos | synologyphotos |
Both providers can be active at the same time.
Configuring a provider
Go to Settings → Integrations. Each enabled provider gets its own settings card there, titled with the provider's name — Immich and/or Synology Photos.
Immich
| Field | Required | Notes |
|---|---|---|
| Server URL | Yes | Full URL of your Immich instance, e.g. https://immich.example.com |
| API Key | Yes | Stored encrypted; never returned to the browser after saving |
| Mirror journey photos to Immich on upload | No | Checkbox; when enabled, photos you upload in TREK are also pushed to your Immich library |
Enter the full URL of your Immich instance and an Immich API key. The API key is stored encrypted on the TREK server and is never returned to the browser after it is saved.
Required API key permissions
When generating the API key in Immich (Account Settings → API Keys), grant only the scopes TREK actually uses:
| Permission | Why TREK needs it |
|---|---|
user.read |
Verify the API key and identify the connected account |
timeline.read |
Browse photos by date |
asset.read |
Read photo metadata and search results |
asset.view |
Load thumbnails and preview images |
album.read |
List owned + shared albums and their contents |
asset.download |
Download the assets |
asset.upload |
Only if you enable "Mirror journey photos to Immich on upload" — push TREK uploads back to your library |
TREK never modifies or deletes anything in Immich, so no update, delete, or admin scopes are needed.
Synology Photos
| Field | Required | Notes |
|---|---|---|
| Server URL | Yes | Full URL including the Photos app path, e.g. https://your-nas:5001/photo |
| Username | Yes | Synology account username |
| Password | Yes | Stored encrypted; leave blank to keep the existing password |
| MFA code (if enabled) | No | One-time password for 2FA; only needed on first connection or when re-authenticating |
| Skip SSL certificate verification | No | Checkbox; disable TLS certificate validation for self-signed certificates |
Required DSM account permissions
Synology Photos doesn't use API keys — TREK signs in with a regular DSM user account. To minimize blast radius, create a dedicated low-privilege DSM user for TREK rather than reusing your admin account:
- A standard (non-admin) DSM user account is sufficient.
- The account must have access to the Synology Photos package (DSM → Control Panel → User & Group → [user] → Applications, allow Synology Photos).
- The account must be able to log in to DSM (not disabled, not IP-blocked).
- Network access to DSM (typically port
5000HTTP /5001HTTPS, or your reverse-proxy host). - 2FA is supported — enter the OTP at first connection; TREK stores the resulting device token so you won't be re-prompted on subsequent saves.
- Read-only access is enough — TREK only lists albums, lists items, runs searches, and fetches thumbnails. It never writes, uploads, or deletes.
Testing the connection
Each provider section has a Test Connection button. Clicking it sends your current field values to the server and attempts to authenticate with the provider. A green "Connected" badge confirms success; any error message from the provider is shown if it fails.
For Synology, a successful test stores a session token so the OTP code is not required again on subsequent saves (as long as the URL and username remain the same).
Multiple providers
You can configure both Immich and Synology simultaneously. TREK queries photos from all enabled providers when loading trip photos.
After setup
Once a provider is connected, you can browse and attach photos to your trips. See Documents-and-Files for how to manage files after setup.