# Reitti: self-hosted location tracking with a stitched personal timeline

> Reitti is an AGPL-3.0 Java application that ingests GPS data from phones and loggers, detects visits and trips, and shows them on a map you host yourself. It ships as a Docker Compose stack with PostGIS, Redis and a tile cache.

**dedicatedcode/reitti** — Reitti is a comprehensive personal location tracking and analysis application that helps you understand your movement patterns and significant places. The name "Reitti" comes from Finnish, meaning "route" or "path".

- Repository: https://github.com/dedicatedcode/reitti
- Website: https://www.dedicatedcode.com/projects/reitti/
- Stars: 2,599 · Forks: 80
- Language: Java
- License: AGPL-3.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/dedicatedcode-reitti

## The problem Reitti solves: your location history living on someone else's servers

Google Timeline and similar services answer a simple question well: where was I on a given day. The cost is that the answer lives in an account you do not control, and exporting it later is a chore. Reitti is aimed at the person who has already decided that trade is not worth it. It is a self-hosted application that stores raw GPS points, groups them into visits and trips, and lets you name the places you return to. The name is Finnish for route or path, which is about as much branding as the project bothers with.

The audience is narrower than the feature list suggests. You need somewhere to run four containers, a way to get location data off your phone, and patience for a settings-driven web UI. The README points at OwnTracks-style ingestion, mobile app integrations, GPX files and Google Takeout JSON as inputs, so the intended user is someone with existing history to migrate, not someone starting from zero. Multi-user support with data isolation and OIDC single sign-on are listed, which suggests households and small groups rather than a single phone.

## How the ingestion pipeline turns raw points into visits and trips

The architecture is a Java service backed by PostGIS and Redis, with a separate nginx-based tile cache in front of map tiles. PostGIS is doing the real work: the application stores GPS points as spatial data, and visit and trip detection is a query problem over those points rather than a streaming heuristic. Redis sits alongside it, presumably for live position state and caching, though the README does not describe what is stored there.

The device model is the part worth understanding before you commit. Each user can have multiple devices. Data ingested into the default device is automatically stitched into one personal timeline. Other devices do not merge on their own; you select the device and a time range in the workbench and stitch manually. That is a deliberate choice. Automatic merging of two loggers with overlapping timestamps and different clock drift produces garbage, so Reitti makes you look at the overlap first. The workbench also lets you drag misplaced points to their correct location and delete outliers, which is the acknowledgement that GPS data is dirty and no detector will be right every time.

Live sharing is a separate path from history. Same-instance sharing exchanges positions between users in real time. Federation exchanges only live positions with other Reitti instances you configure, and the README is explicit that your historical data stays on your own server. Magic links go further and expose a live position, and optionally a recent track, to someone with no account, revocable at any time. Reverse geocoding works out of the box against hosted Paikka instances, which is a real dependency to note: the default configuration sends coordinates to a third party unless you configure your own geocoder.

## Installing Reitti with Docker Compose and connecting a first device

The quick start is a directory, a downloaded compose file and one command. The compose file pulls `dedicatedcode/reitti:5`, `postgis/postgis:17-3.5-alpine`, `redis:7-alpine` and `dedicatedcode/reitti-tile-cache:5`, and the application waits on health checks from the other three before starting.

```bash
mkdir reitti && cd reitti
wget https://raw.githubusercontent.com/dedicatedcode/reitti/refs/heads/main/docker-compose.yml
docker compose up -d
```

After the containers report healthy, the web UI is on port 8080. The README states that first login prompts you to set a new admin password and that a default API token is created automatically, so you can connect a device without visiting a token screen first.

```yaml
services:
  reitti:
    image: dedicatedcode/reitti:5
    ports:
      - 8080:8080
    environment:
      POSTGIS_USER: reitti
      POSTGIS_PASSWORD: reitti
      POSTGIS_DB: reittidb
      POSTGIS_HOST: postgis
```

The credentials above are the ones shipped in the repository compose file. They are fine for a first run on a laptop and wrong for anything reachable from a network. Change `POSTGIS_PASSWORD` and the matching `POSTGRES_PASSWORD` before the container is exposed.

The README's next steps are menu paths, not commands: `Settings → Devices` to add a device, `Settings → Integrations` to connect a mobile app with the default token, `Settings → Import Data` for GPX, Google Takeout JSON or a Google Timeline export, `Settings → Map Styles` to upload a style file or link a remote style URL, and `Settings → Live Sharing` for sharing. If you are on Apple Silicon or another ARM64 host, the README says to change the PostGIS image to `imresamu/postgis:17-3.5-alpine` until postgis/docker-postgis#216 is resolved. That is a prerequisite, not an optional tweak.

## Where Reitti gets awkward: operations, data hygiene and the wrong use cases

Four containers is a real operational footprint. PostGIS alone wants memory, and the tile cache exists because map tiles are expensive to fetch repeatedly. On a small VPS or a Raspberry Pi with limited RAM, this stack will be the largest thing running. The README does not publish minimum requirements, so sizing is guesswork until you watch it under your own data volume.

The workbench is a double-edged feature. Being able to drag points and delete outliers means the application accepts that its own detection is imperfect and hands you the cleanup. If you expect to import a decade of Google Takeout and get a clean timeline with no manual work, that expectation is not supported by anything in the README. Stitching non-default devices is explicitly manual, which is the correct design and also the tedious one.

Reverse geocoding is the privacy seam. Self-hosting keeps your raw data local, but the default geocoder is a hosted Paikka instance, meaning place names come from a service you do not run. The README says you can configure your own geocoder instead. If the point of the deployment is that coordinates never leave the network, that configuration is not optional.

Finally, Reitti is not a navigation app and not a fitness tracker. There are statistics and transport-mode detection, but the README describes them as summaries of movement patterns, not training analysis. If you want per-activity heart rate and segment comparisons, this is the wrong tool.

## Reitti compared with Dawarich and GeoPulse

The related searches pair Reitti with Dawarich and GeoPulse, and the honest difference is in scope and stack. Dawarich is the closest comparison in purpose: a self-hosted location history app that ingests OwnTracks data and renders a timeline. The practical distinction visible here is Reitti's device model and workbench. Reitti treats multiple devices as a first-class problem with manual stitching and point-level editing on the map, and it adds federation between instances and revocable magic links for people without accounts. If your problem is one phone and one clean timeline, that machinery is overhead you will not use.

GeoPulse appears in the same searches as another self-hosted alternative in this space. The README gives no comparison, so the only defensible statement is about deployment: Reitti's documented install is a four-service Compose stack with PostGIS, Redis and a dedicated tile cache, which is a heavier dependency set than a single-container application. That matters if you are choosing for a constrained host.

Against Google Timeline the trade is inverted. You give up the polished mobile experience and the zero-setup ingestion, and you get a PostGIS database you can query, export and back up yourself. Reitti also imports Google Takeout JSON and Google Timeline exports, so the migration path off Google is documented rather than theoretical. The Immich integration is the other differentiator worth naming: photos from a self-hosted Immich server appear on the timeline at the locations where they were taken, which is a feature that only makes sense if you already run Immich.

## Maintenance, releases and what AGPL-3.0 means for a self-hoster

The repository is not archived and the last push was on 2026-09-24, three days before this writing. The release cadence is visible in the tags: v5.4.0 on 2026-09-07, v5.5.0 on 2026-09-12, v5.5.1 on 2026-09-21. That is three releases in a month, which is fast enough that pinning matters. The compose file uses the `dedicatedcode/reitti:5` tag, so a `docker compose pull` will move you across minor versions without asking. If you want to choose when that happens, pin to a specific patch tag instead.

Upgrades are the standard Compose dance: pull the new image, recreate the containers, and let the application run its own migrations against PostGIS. The README does not document rollback, and it does not document a backup procedure for the `reitti-data` and `postgis-data` volumes. Those volumes are where everything lives. Treat a database dump as your own responsibility, because the project does not describe one.

The licence is AGPL-3.0, which is the strongest of the common copyleft licences and includes the network-use clause. Running Reitti for yourself or your household is the ordinary case and the licence is not a concern there. If you plan to modify it and offer it to others as a service, the obligations are different and you should read the licence text rather than an article. Nothing here is legal advice.

## Conclusion

Reitti fits people who already run a home server, want their GPS history in their own PostGIS database, and are willing to feed it from OwnTracks, GPSLogger or a file import. It does not fit anyone who wants a hosted service with a polished mobile app, and it does not fit a single-board machine with 1 GB of RAM, since the stack is four containers. Before adopting it, verify the ARM64 PostGIS workaround applies to your hardware, check that the default admin password prompt appears on first login at port 8080, and confirm which import formats your existing history is stored in.

## FAQ

### What is Reitti and who is it for?

Reitti is a self-hosted personal location tracking and analysis application that identifies the places you spend time and the movements between them. It is for people who want their GPS history stored on their own infrastructure rather than in a hosted account.

### How do I install Reitti?

The README's quick start creates a directory, downloads docker-compose.yml from the repository, and runs docker compose up -d, after which the web UI is on http://localhost:8080. On first login you are prompted to set a new admin password.

### What are the alternatives to Reitti?

Dawarich and GeoPulse appear alongside Reitti in the searches for this project, and both are self-hosted location history tools. The documented difference is deployment weight: Reitti's install is a four-service Compose stack with PostGIS, Redis and a dedicated tile cache.

### Does Reitti work with OwnTracks and GPSLogger?

The repository topics list owntracks-recorder, and the README's integrations section covers mobile apps connected through Settings, using the default API token that is created automatically. GPSLogger appears in the related searches but the README excerpt does not give a separate GPSLogger setup page.

### Can Reitti share my live location with other people?

Yes. The README describes same-instance sharing between users, federation that exchanges only live positions with other Reitti instances you configure, and magic links that let someone without an account see your live position and optionally a recent track. Magic links are revocable at any time.

### Does Reitti integrate with Immich?

The README states that Reitti integrates with a self-hosted Immich server and that photos taken at specific locations and dates appear on your timeline, with a full-screen viewer and galleries.

## Sources

- [dedicatedcode/reitti on GitHub](https://github.com/dedicatedcode/reitti)
- [License: AGPL-3.0](https://github.com/dedicatedcode/reitti/blob/main/LICENSE)
- [Project website](https://www.dedicatedcode.com/projects/reitti/)
- [README](https://github.com/dedicatedcode/reitti/blob/main/README.md)
- [Releases](https://github.com/dedicatedcode/reitti/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dedicatedcode-reitti