Dawarich: a self-hosted replacement for Google Timeline

The problem Dawarich takes off Google's servers

Google Timeline kept a continuous record of where you went. That record lived in a Google account, was rendered by Google's map, and was searched by Google's index. Dawarich moves the same job onto hardware you control. It is a web app that ingests location points from a phone, stores them in PostgreSQL, and draws them back as a map, a timeline, and a set of statistics.

The audience is narrower than the tagline suggests. The README's own setup path assumes Docker, a compose file, and a server that stays up. That is a reasonable ask for a homelab operator with an existing reverse proxy and a Postgres habit. It is a poor fit for someone who wants an app store download and a login. The project does not hide this: the README points at a Docker setup page and a Synology tutorial, and the repository ships a docker/ directory rather than a desktop installer.

The feature list is where the ambition shows. Beyond the map, Dawarich computes countries and cities visited, total distance traveled, time spent per place, and days spent in each country, which the README explicitly flags as useful for tax residency questions. It also has a Family page for sharing location with consenting members, and integration hooks for Immich and Photoprism so geotagged photos appear on the same map as your points.

How location data actually moves through Dawarich

There is no Dawarich-built GPS. The README lists the clients it accepts: Dawarich for iOS, Dawarich for Android, the community Android app at sunstep/dawarich-android, Overland, OwnTracks, GPSLogger, PhoneTrack, and Home Assistant. You install one of those, point it at your instance, and it posts location updates. Dawarich is the receiver and the store, not the sensor.

On the server side the shape is conventional Rails. PostgreSQL holds the data, Redis backs background work, and the .env.example file confirms this split by declaring DATABASE_HOST, DATABASE_PORT, DATABASE_NAME, DATABASE_USERNAME, DATABASE_PASSWORD and REDIS_URL as required variables, and noting that config/database.yml reads those discrete variables rather than a single DATABASE_URL. Two JWT secrets, JWT_SECRET_KEY and AUTH_JWT_SECRET_KEY, are also required and are described as being used for subscription tokens and mobile auth challenge and link tokens.

The interesting work happens in background jobs. The .env.example exposes PLACE_VISITS_THROTTLE_SECONDS, described as the pause between places in the nightly place-visit job, with the comment that raising it helps on large databases where the job otherwise saturates the database and delays point ingestion. That is a real design constraint made visible: visit detection is a batch process that competes with live writes. The same file exposes a statement timeout for vector tile queries under tiled rendering, with the note that cancelled tile queries appear as cancelling statements and that self-hosted instances with very large date ranges may need to raise it. Both variables tell you the same story. Dawarich is tuned for a personal dataset, and the knobs exist because the defaults start to hurt as the dataset grows.

Starting Dawarich with docker compose on port 3000

The README's local path is two steps. Clone the repository, then run the compose file from the docker directory:

docker compose -f docker/docker-compose.yml up

When the stack finishes starting, the app answers at http://localhost:3000. The README states that the default credentials are [email protected] with the password safepassword, and that you can change them in account settings. Change them before the instance is reachable from anywhere but your own machine.

The README says you can use the default values or create a .env file based on .env.example to customize the setup. If you go the .env route, the required values are the database block and Redis. The .env.example also carries OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES as an optional macOS-only setting, described as preventing objc fork-safety warnings and crashes when Sidekiq forks.

DATABASE_HOST=localhost
DATABASE_PORT=5432
DATABASE_NAME=dawarich_development
DATABASE_USERNAME=postgres
DATABASE_PASSWORD=
REDIS_URL=redis://localhost:6379

To stop the app, press Ctrl+C. For a real deployment the README points to a Docker setup page and a Synology tutorial rather than describing a production compose file in the repository root, so treat the local command as a way to see the app, not as the deployment guide.

Importing a Google Timeline export and where it stops

The import path is the reason many people arrive. Dawarich accepts Google Maps Timeline exports, OwnTracks data, Strava, Immich, GPX and GeoJSON files, and EXIF data from photos. The README links a guide titled Import Google Takeout under the tutorials section.

One instruction in the README deserves to be read twice. It says not to delete your original data after importing into Dawarich. That is not boilerplate caution. It is an admission that the imported copy is not the authoritative one, and it pairs with the updating section, which says automatic updates may break your setup and that you should back up before upgrading. If you delete the Takeout archive, the only remaining copy sits in a database that the maintainer warns can be disrupted by an upgrade.

Export is supported to GeoJSON and GPX, which is the escape hatch worth knowing about. Before you invest months of tracking into the instance, confirm that the export produces a file you can actually read back, because that is your recovery path if an upgrade goes wrong and your backup is stale.

The update model is the real cost of running Dawarich

The README's disclaimer is unusually blunt for a project page. It states that the project is under active development, that you should expect frequent updates, bugs, and breaking changes, and that you should not update automatically and should read release notes before updating. The last push to the repository was on 2026-08-27, and releases 1.13.0, 1.13.1 and 1.14.0 all landed in August 2026, which is consistent with the warning: the release cadence is fast.

For a self-hoster this changes the maintenance budget. You are not paying for a server; you are paying attention. Every upgrade is a read-the-notes task followed by a backup. If you run Dawarich on a schedule you do not control, or you let a watchtower-style tool pull new images, you are doing precisely what the README tells you not to do.

The licence adds a second consideration. Dawarich is AGPL-3.0. For personal self-hosting that is unremarkable. If you were considering embedding Dawarich in a service you offer to others, the network-copyleft terms of the AGPL are the part to read carefully, and that is a question for a lawyer rather than for a review.

Where Dawarich is the wrong tool

The tracking clients are the weak point, and the README is honest about it by listing so many. Dawarich for iOS and Dawarich for Android exist, but there is also a separate community Android app, plus Overland, OwnTracks, GPSLogger and PhoneTrack. That spread suggests no single client is the obvious default, and it means your tracking reliability depends on a third-party app's background location behaviour, not on Dawarich itself. On mobile operating systems, background location is where apps get killed.

The second failure mode is scale. The two tuning variables in .env.example, PLACE_VISITS_THROTTLE_SECONDS and the tile statement timeout, both exist because batch work and map rendering degrade as the dataset grows. A user with years of dense points and a habit of viewing multi-year ranges on the map is exactly the user those comments describe. Dawarich will still store the data; the question is whether the map stays responsive.

If you want a managed service, Dawarich Cloud exists and the README links to it. If you want a tracker that never asks you to read release notes, this is not it.

Dawarich against the alternatives people actually compare it to

The obvious alternative is Google Timeline itself, and the difference is not features. Google's version requires no server, no backups, and no upgrades, and it is free in the sense that you pay with the data. Dawarich inverts all three. You supply the hardware, you own the backup problem, and you keep the data. If you value the first column more than the second, Google Timeline wins and no amount of map layers changes that.

Among self-hosted options, the meaningful contrast is with OwnTracks' own recorder. OwnTracks is listed in Dawarich's README as a supported client, and it can store points on its own. The difference is what sits on top. OwnTracks gives you a feed of positions; Dawarich adds the interpretation layer: trips, visits, areas, statistics, days-in-country, family sharing, and photo integration through Immich or Photoprism. That layer is the product. If you only need a raw track log you can query, Dawarich is more machinery than the job requires.

A third comparison worth making is against a general-purpose dashboard approach, where you push location into Home Assistant and chart it there. Home Assistant is also listed as a supported source for Dawarich, so the two are not exclusive. The split is that Home Assistant excels at reacting to state changes in the moment, while Dawarich is built for looking backwards across months and years. Use the first for automation, the second for history.

What to check before you point a phone at it

Start the compose stack and confirm the app boots at http://localhost:3000 with the demo credentials, then change them. Set the required database and Redis variables from .env.example in a .env file rather than relying on defaults, and generate the two JWT secrets with the command the file names:

bundle exec rails secret

Next, put a reverse proxy in front of it, because the README's tracking tutorials assume your phone can reach the instance over the network, and you should not expose port 3000 directly. Then pick one client, connect it, and watch a single day of points arrive before importing years of history. Importing first and debugging second makes it hard to tell whether a gap is a bad import or a dead client.

Finally, prove your backup. The README links a backup and restore tutorial and tells you to back up before updates. A backup you have never restored is a guess. Restore it once into a scratch instance, and you will know exactly what an upgrade costs you.

Editorial conclusion

Adopt Dawarich if you already run Docker and PostgreSQL, want your location points on your own disk, and can accept reading release notes before every upgrade. Do not adopt it if you need a set-and-forget service, or if losing months of track data during a botched update would be unacceptable. Before you commit, verify three things: that the docker/docker-compose.yml stack boots on your host and answers on port 3000, that your chosen tracking client can reach your instance over HTTPS, and that you have a working backup and restore path, since the README links a backup tutorial and warns that automatic updates may break your setup.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes