Deploy and Host TREK on Railway

TREK is a self-hosted, collaborative travel planner. Plan trips day by day on an interactive map, keep bookings, budgets, packing lists and documents in one place, and edit together with friends in real time. A built-in MCP server lets your own AI assistant read and update your trips.

About Hosting TREK

TREK runs as one Node.js service with a SQLite database. This template deploys the official, unmodified mauriceboe/trek image pinned to v5.1.1, with one Railway volume that holds both the database and every uploaded file (covers, photos, documents, avatars). Your trips survive redeploys, restarts and upgrades.

You fill in one field at deploy time: the e-mail address for your admin account. The admin password and the encryption key are generated for your deployment.

This is a community template. It is not made or endorsed by the TREK project.

Common Use Cases

Plan a trip day by day: places on a map, routes, opening hours and notes per day
Plan a group trip with friends or family, all editing at the same time
Keep flights, hotels, tickets and booking documents with the trip they belong to
Track a shared travel budget and split costs
Packing lists and to-dos with reminders before you leave
Let Claude, ChatGPT or any MCP client plan and edit trips through TREK's MCP server

Dependencies for TREK Hosting

A volume for the SQLite database and uploads (included)

Deployment Dependencies

TREK source: https://github.com/liketrek/TREK
Documentation: https://github.com/liketrek/TREK/wiki
Image: https://hub.docker.com/r/mauriceboe/trek

Implementation Details

First login. When the deploy turns green, open the TREK service's Variables tab and copy ADMIN_PASSWORD. Open your TREK URL and sign in with the e-mail you entered at deploy time and that password. Change the password in Settings after you sign in. ADMIN_EMAIL and ADMIN_PASSWORD are used only on the first boot, when the database is empty. Changing them later does nothing.

Sign-ups. Control who can register in Admin, Settings. Invite people to a trip from the trip's member list.

Back up your encryption key. ENCRYPTION_KEY encrypts stored API keys and SSO secrets. Copy it somewhere safe. Do not change it after the first boot, or TREK cannot read those values.

Storage. The volume is mounted at /trek. The database lives in /trek/data and uploads in /trek/uploads. TREK's own backup feature (Admin, Backups) writes to the same volume, so also download a backup now and then.

Optional settings (add them to the TREK service at any time, then redeploy):

Custom domain: add it in the service's Networking settings, then set APP_URL to https://your.domain and add it to ALLOWED_ORIGINS.
Google place search and photos: PLACES_API_KEY (Google Maps key with Places API (New)). Without it, TREK uses its own places service and OpenStreetMap.
Trip cover search: UNSPLASH_ACCESS_KEY. Unsplash blocks some cloud IP ranges for anonymous requests, so set a free key if cover search returns nothing.
E-mail for invites and password resets: SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS, SMTP_FROM. Use your own mail provider.
Single sign-on: OIDC_ISSUER, OIDC_CLIENT_ID, OIDC_CLIENT_SECRET, OIDC_DISPLAY_NAME.
Keep place searches on your instance: TREK_PLACES_ENABLED=false.

Logs. On boot, TREK prints one line for every API route, and Railway reports "rate limit reached" for those lines. That is expected and harmless.

Upgrading. Change the TREK service's image tag to a newer release (for example mauriceboe/trek:5.2.0) and redeploy. Migrations run on boot. Download a backup first.

Scaling. TREK uses SQLite, so it runs as a single instance. Add more CPU and memory to the service if a large group plans at the same time.

Why Deploy TREK on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.