GeoPulse: A Self-Hosted Timeline Built on PostGIS, OwnTracks and Immich
A self-hosted, privacy-first location timeline platform: an open-source alternative to Google Timeline with automatic trip detection, Immich integration, and rich analytics.
At a glance
- What is it?
- GeoPulse turns raw GPS points from OwnTracks, Overland and similar apps into stays, trips and analytics on your own server. The architecture is a Quarkus backend over PostGIS with a Vue 3 frontend, and the licence badge says BSL 1.1, which is the detail to check before you commit.
- Who is it for?
- GeoPulse fits engineers who already run OwnTracks or Overland, want their points in their own PostgreSQL, and are willing to read the BSL 1.1 terms before deploying it for anyone but themselves. Skip it if you need a hosted service with an SLA, or if you only want a map of a single GPX file.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap GeoPulse fills: your points, your database
Google Timeline stores location history in an account you do not control, and the export formats it produces are awkward to query. GeoPulse takes the opposite position. The README describes it as "a self-hosted, privacy-first location timeline platform" and an "open-source alternative to Google Timeline", and the repository topics confirm the stack: java, quarkus, postgis, postgres, vue3, owntracks. The problem it solves is specific. You already have a phone app emitting location points, and you want those points stored in a database you own, turned into a readable history of where you stopped and how you moved, without shipping the raw trace to a third party.
The audience is narrower than the tagline suggests. This is for someone comfortable running docker compose, who has a PostgreSQL instance or is willing to let the compose file create one, and who cares that the data never leaves the host. The README lists the ingestion sources explicitly: OwnTracks over HTTP or MQTT, Overland, Dawarich, GPSLogger, Home Assistant, Traccar and Colota. If your tracker is not on that list, the project expects you to feed it through one of the import paths instead.
How the pipeline works: points in, stays and trips out
The mechanism visible in the material is a conversion step. GeoPulse ingests raw GPS points from the supported trackers and, per the feature list, "automatically converts GPS points into stays, trips, and data gaps". That classification is the core of the product. A stay is a period where the device did not move meaningfully, a trip is a movement segment between stays, and a gap is a hole in the data where the tracker stopped reporting. The README states the detection sensitivity and travel mode classification are "fully configurable", so the thresholds are exposed rather than hardcoded.
Storage is PostGIS, which matters for what the analytics can do. Distance, visit frequency and movement patterns over time are spatial queries against the point table, not application-side loops. The frontend is Vue 3, served separately from the Quarkus backend. GeoPulse also ships a map matching feature that is "Valhalla-backed" and refines noisy trip paths so they follow roads, with the README noting that "raw GPS remains authoritative". That is the right default: the corrected geometry is a display layer, and the original points stay queryable.
Two integrations extend the timeline. Immich photos are placed on the map by timestamp, and Memos notes appear alongside the timeline. Weather enrichment is on by default for trips, stays, map layers and journey insights, with historical backfill as an admin opt-in, per the linked weather processing document. The MCP server added in v1.39.0 exposes "read-only, API-token-authenticated tools" so an AI client can query the timeline and permitted friend data.
Getting it running with Docker Compose
The README gives a three-command path. Create a directory, pull the example environment file and the compose file from the repository, then start the stack:
mkdir geopulse && cd geopulse curl -L -o .env https://raw.githubusercontent.com/tess1o/GeoPulse/main/.env.example curl -L -o docker-compose.yml https://raw.githubusercontent.com/tess1o/GeoPulse/main/docker-compose.yml docker compose up -d
The service listens on port 5555, so the first login is at http://localhost:5555. The README adds a warning that is easy to skim past: "For production, review your .env for security-related settings first." The example file is the only configuration surface documented in the material I have, and the specific keys inside it are not reproduced in the README, so treat the file itself as the reference.
Alternative install paths are documented on the project site rather than in the README body: Unraid, Proxmox VE LXC, Kubernetes with Helm (including a separate Helm values reference), and a manual installation for bare metal or VMs without Docker. MQTT support for OwnTracks is called out as something that needs the deployment options page rather than the quick-start. If you want OwnTracks over MQTT instead of HTTP, that is the page to read before you pick an install method.
The licence badge says BSL 1.1, and the repository metadata disagrees
This is the first thing to resolve. The README carries a shields.io badge reading "License BSL_1.1", and the project describes itself as open source. The repository metadata supplied here reports the licence as NOASSERTION, which is GitHub's way of saying it could not map the LICENSE file to a known SPDX identifier. Those two signals do not match, and the discrepancy is not something I can settle from the material I have.
Business Source License 1.1 is a source-available licence, not an OSI-approved open source licence. Typical BSL terms restrict production use above a revenue or headcount threshold and convert to a stated open licence after a change date, but the change date, the converting licence, and the additional use grant are all set per project and are not reproduced in the README. Before you deploy GeoPulse for a company, a client, or anyone other than yourself, read the LICENSE file at the repository root and confirm what the grant actually permits. I am not giving legal advice here; I am pointing at the one document that decides whether your use is allowed. The README's own framing ("open-source, privacy-first Google Timeline alternative") and the badge (BSL 1.1) are in tension, and that tension is the project's to resolve, not the reader's to assume away.
Where GeoPulse is the wrong tool
The lightweight runtime claim is the one to treat carefully. The README says "typically under 100MB RAM and under 1% CPU in regular usage". That is a statement about regular usage, and regular usage is not the same as a bulk import of years of Google Timeline history into PostGIS, or a backfill of historical weather across every trip you have ever recorded. Budget for the import to be heavier than the steady state, and do not size a small VPS on the 100MB figure alone.
The bigger structural limitation is the dependency on a tracker that actually reports. GeoPulse classifies stays, trips and gaps from incoming points, so the quality of the timeline is bounded by the quality of the feed. A phone that kills the location app in the background produces gaps, and gaps are a first-class output of the detection logic rather than something the server can repair. If your tracker is not among OwnTracks, Overland, Dawarich, GPSLogger, Home Assistant, Traccar or Colota, you are on the import path, which is a batch workflow, not live tracking.
There is also a scope limit worth naming. GeoPulse is a timeline and analytics product. It is not a routing engine, not a fleet management system, and not a replacement for a dedicated GIS. The Valhalla map matching refines displayed paths; it does not turn GeoPulse into a navigation tool. Multi-user features (friends, guest links, invitations, roles, OIDC/SSO) exist, but if your actual requirement is organisational location compliance with retention policy enforcement, the README does not describe that.
Dawarich and the difference in approach
Dawarich appears twice in the material: as an ingestion source GeoPulse can read from, and as the obvious comparison point. Both projects occupy the self-hosted Google Timeline niche, and the split is architectural. GeoPulse is Java on Quarkus with PostGIS and a Vue 3 frontend, and the README leans on Quarkus-native topics. Dawarich is a Rails application in the same category. The practical difference a reader should weigh is not features, it is operational fit: which runtime your host already runs well, and which one your team can patch when it breaks.
The second difference is scope. GeoPulse's distinguishing additions in the material are the Immich, Memos and Weather integrations, the Valhalla map matching, and the MCP server for AI clients. If your photo library is already in Immich, the timestamp-based photo placement is the reason to pick GeoPulse over a plain timeline. If you have no Immich and no interest in an MCP endpoint, that advantage disappears and the choice reduces to stack preference. Note that GeoPulse can consume Dawarich as a source, so the two are not mutually exclusive in a migration: you can point GeoPulse at an existing Dawarich instance rather than re-flashing your phone.
Upgrade cadence and what it costs you to stay current
The release history in the material is dense. v1.38.0 (Map Matching, Admin Backups) landed on 2026-09-03, v1.38.1 was a "regression fix" the next day, and v1.39.0 (MCP, Panoramax, Trip Split) arrived on 2026-09-07. Three releases in five days, one of them explicitly a regression fix. That pattern tells you something concrete: features ship fast, and you should expect to run a recent version rather than pinning to something a year old and assuming it still matches the documentation.
On the operational side, the README documents encrypted, password-protected full backups with manual restore and scheduled automatic backups, and v1.38.0 added admin backups. Use them before upgrading, because the release notes show regressions do reach tagged releases. The backup and restore guide is linked from the project site. Data export is also listed as a feature, which is the exit path if the licence terms or the maintenance burden stop working for you.
On licence cost specifically: the material does not state a price, a seat limit, or a revenue threshold. The only licence fact available is the BSL 1.1 badge and the NOASSERTION metadata. Until you read the LICENSE file, treat the commercial terms as unknown, and treat "open source" in the tagline as the project's own description rather than a verified legal status.
Editorial conclusion
GeoPulse fits engineers who already run OwnTracks or Overland, want their points in their own PostgreSQL, and are willing to read the BSL 1.1 terms before deploying it for anyone but themselves. Skip it if you need a hosted service with an SLA, or if you only want a map of a single GPX file. Verify first: the exact BSL change date and what it converts to, and whether your GPS source's payload format is covered by the importers listed in the README.
Community notes