Deploy and Host FitTrackee on Railway

FitTrackee is a self-hosted training log. Upload the GPS file from a run, ride, hike or ski tour and it draws the route on a map, works out distance, pace and elevation, and builds statistics across months and years. Twenty-nine sports, GPX, FIT, TCX and KML imports, and an API other apps can push to. This is a community-maintained template; it is not affiliated with the FitTrackee project.

About Hosting FitTrackee

FitTrackee is straightforward to host: one application container and one database. The database has to be PostgreSQL with the PostGIS extension, because the migrations create spatial columns, so a plain managed PostgreSQL will not do; this template ships the PostGIS image with its own volume. The application keeps uploaded tracks, workout pictures and its map cache in a second volume.

The part that needs care is who can sign up. A fresh instance has no user limit, and the application reads that as unlimited, so registration is open to anyone who finds the address. Worse, the first account to register is an ordinary user: the owner role is granted by a command run against the container, so on a fresh public instance nobody holds the rights to close the door standing open. This template creates your account with the owner role before the public port is opened, then closes registration through the application's own settings. It never lowers a limit you raised yourself, so inviting other people later is not undone by the next deploy.

Why Deploy FitTrackee 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.

By deploying FitTrackee on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Concretely, this template provisions the PostGIS database and the application, wires the connection string, attaches both volumes and fixes their ownership, generates your password and the application secret, runs the migrations, creates your account and closes registration, with nothing to fill in.

Common Use Cases

Keep years of training history on infrastructure you control instead of a commercial fitness platform that can change its terms or its export policy.
Import a lifetime of GPX files exported from another service and see the whole record in one place.
Track several sports side by side and compare seasons rather than single sessions.
Run a private log for yourself, or raise the user limit and share one instance with a small club.

Dependencies for FitTrackee Hosting

PostgreSQL with the PostGIS extension. This is not optional; the migrations need it.
A persistent volume for uploaded tracks, pictures and the map cache.
Optionally a Redis service and a worker process for data export, archive uploads and e-mail. This template leaves those out, which is the setup upstream calls minimal.

Deployment Dependencies

FitTrackee upstream project: https://github.com/SamR1/FitTrackee
Configuration reference: https://samr1.github.io/FitTrackee/en/installation/environments_variables.html
Caddy, used as the gate that holds the public port shut until the instance is claimed: https://caddyserver.com
Template repository, wrapper image and tests: https://github.com/youssefsiam38/fittrackee-railway
Published image: ghcr.io/youssefsiam38/fittrackee-railway
FitTrackee is licensed AGPL-3.0-only. Running it as a network service makes you a distributor under section 13, so keep the corresponding source of the version you run available.

Implementation Details

The wrapper adds no application code. It validates the configuration and refuses the placeholder secret key shipped in the project's example file, takes ownership of the volume for the user the application runs as, runs the migrations, starts the application on loopback, creates the owner account through the project's own command line tool, and closes registration through its configuration API before opening the public port. That command reports failures on standard output while still exiting successfully, so the wrapper reads what it printed rather than trusting its exit status.