OwnTracks Frontend

Open-source location tracking dashboard, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

• What it is: A Vue.js single-page application that adds a proper web dashboard to OwnTracks Recorder — the basic recorder UI is functional but minimal; this replaces it with heatmaps, history playback, and live location tracking [1].
• Who it’s for: Privacy-conscious individuals and small families who are already running OwnTracks (or planning to) and want a usable web interface to visualize location data. Not a standalone product — it requires OwnTracks Recorder as the backend [1].
• Cost savings: Commercial family location apps (Life360 Premium, Apple One with Find My, Google Maps location sharing) run $10–$30/mo. OwnTracks Frontend is MIT-licensed, runs on a $5/mo VPS alongside the Recorder, and costs nothing for the software itself [1].
• Key strength: Clean, purpose-built map interface with heatmaps, date-range filtering, and accurate device-specific history — functionality that the stock Recorder UI doesn’t offer [1].
• Key weakness: It’s a frontend only. You need to set up OwnTracks Recorder (a separate Go binary or Docker container) and the OwnTracks mobile app on every device before this web UI has anything to show. The setup chain is three components deep before you see a dot on the map [1].

---

What is OwnTracks Frontend

OwnTracks Frontend is a web interface for the OwnTracks location tracking ecosystem, built as a Vue.js single-page application. The README is explicit about its scope: “The recorder itself already ships with some basic web pages, this is a more advanced interface with more functionality, all in one place.” [1]

To understand what this tool is, you need to understand what it isn’t. OwnTracks Frontend doesn’t track anything by itself. It’s the visualization layer on top of a three-part stack:

1. OwnTracks mobile apps (Android or iOS) — installed on each device to be tracked, publishing location via MQTT or HTTP
2. OwnTracks Recorder — the backend service that receives, stores, and serves location data via a REST API
3. OwnTracks Frontend (this tool) — the Vue.js dashboard that queries the Recorder API and renders everything on a map

The GitHub repository has 528 stars and 65 forks as of this review — modest numbers that accurately reflect this is a component in a niche ecosystem rather than a standalone product with mass appeal [1]. It’s MIT-licensed, which matters because you can fork it, modify it, deploy it commercially, or embed it in your own tooling without licensing negotiations.

The project is active: 322 commits, GitHub Actions CI running build, test, and lint workflows, and 35 releases shipped [1]. It’s not a dead project someone abandoned after building v1.

---

Why people choose it

The choice to use OwnTracks Frontend specifically is downstream of a prior decision: choosing the OwnTracks ecosystem for self-hosted location tracking in the first place. Once you’ve committed to running OwnTracks Recorder, the question becomes which frontend to use — the stock pages bundled with the Recorder, or this standalone SPA.

Versus the built-in Recorder UI. The stock OwnTracks Recorder ships with basic web pages, but they’re functional rather than polished. The Frontend project exists specifically because the built-in pages weren’t enough for users who wanted heatmaps, combined history views, device filtering, and accurate range controls in one interface [1]. If you’re running Recorder and wondering why you’d bother adding this, the heatmap and combined location history features are the main answer.

Versus commercial alternatives. The privacy argument for the whole OwnTracks ecosystem is simple: Life360, Google Maps location sharing, and Find My all route your location through someone else’s servers. With OwnTracks, the data never leaves infrastructure you control. OwnTracks Frontend is the piece that makes that data usable in a browser without requiring SSH access to query raw files [1].

Versus building your own. Some technically capable users run OwnTracks Recorder and query its API directly with custom scripts or Grafana. OwnTracks Frontend offers an out-of-the-box alternative that doesn’t require you to build a map UI from scratch, with Docker deployment and a config file as the setup path [1].

---

Features

Based on the README and repository [1]:

Live location tracking:

• Last known location for each tracked device displayed on the map
• Accuracy visualization as a circle around each point (useful for understanding GPS signal quality)
• Device-friendly names and icons
• Detailed info popups: time, latitude, longitude, altitude, battery level, speed, and regions (geofences) when data is available

Location history:

• Historical data points, a continuous line, or both displayed simultaneously
• Date and time range picker to scope the displayed data
• Filter by user or by specific device under that user
• Distance travelled calculation for the selected range

Visualization:

• Location heatmap — a full density overlay for any time range, useful for seeing patterns across days or weeks
• “Fit to view” button that zooms the map to encompass all visible objects automatically

Customization and configuration:

• Highly customizable via a JavaScript config file (config.js) — no recompilation required for most settings
• Works zero-configuration if the OwnTracks Recorder API is at the same host root as the frontend; otherwise a single config file change points it at the right host and port [1]

Deployment:

• Pre-built Docker image on Docker Hub (owntracks/frontend) with environment variable configuration
• Docker Compose-compatible with the standard OwnTracks Recorder compose setup
• Manual npm build for bare-metal or custom webroot deployments

Internationalization:

• Vue I18n support with German translations already merged; additional locales follow the same pattern [1]

Developer experience:

• Hot-reload dev server, CORS proxy script for developing against a production Recorder instance, lint and format pipelines for JS/Vue/SCSS/Markdown [1]

---

Pricing: SaaS vs self-hosted math

OwnTracks Frontend has no SaaS tier — it’s purely self-hosted MIT software. The relevant pricing comparison is the whole OwnTracks stack versus commercial location sharing services.

Commercial location sharing (what you’re escaping):

• Life360 Premium: ~$7.99/mo, $14.99/mo for more features. Covers your family but your location data lives on Life360’s servers.
• Apple One (includes Find My): $19.95–$32.95/mo, but Find My is limited to Apple devices and doesn’t give you a web dashboard with history or heatmaps.
• Google Maps location sharing: free, but routes everything through Google.

OwnTracks stack self-hosted:

• OwnTracks mobile apps: free on Android and iOS
• OwnTracks Recorder: free, MIT-licensed Go binary
• OwnTracks Frontend: free, MIT-licensed
• Infrastructure: $5–10/mo for a VPS that can comfortably run the Recorder and serve the Frontend (Hetzner, Contabo, DigitalOcean)
• Domain + TLS: $10–15/yr if you don’t already have a domain

Concrete math: Life360 Premium for a family of four runs ~$96–$180/year. OwnTracks self-hosted runs ~$60–$120/year in VPS costs — for software you control, with data that never leaves your server. The savings are real but not dramatic; the more compelling reason to self-host is data sovereignty, not cost.

If you already run a VPS for other services, the marginal infrastructure cost of adding OwnTracks is close to zero — the Recorder is lightweight and the Frontend is a static SPA served by the nginx container.

---

Deployment reality check

This is the section that most matters for non-technical founders, and it’s where OwnTracks Frontend requires the most honest assessment: this is not a one-container setup.

What you actually need before the Frontend shows anything:

1. A working OwnTracks Recorder instance (separate Docker container or binary), with its API accessible to the Frontend container
2. OwnTracks mobile app installed and configured on each device to be tracked — pointing at your Recorder’s MQTT or HTTP endpoint
3. A reverse proxy (Caddy or nginx) with TLS if you want HTTPS access from outside your network
4. Optionally: MQTT broker (Mosquitto) if you’re using MQTT instead of HTTP mode

The docker-compose path is the most practical route. The Frontend README’s compose example assumes the Recorder service is already named otrecorder in the same compose stack, which is the right mental model [1]. If you set up the Recorder first (as you should), adding the Frontend is a matter of dropping in the additional service block and pointing SERVER_HOST at it.

What can go sideways:

• Three-component dependency chain. You need the mobile app, the Recorder, and the Frontend all configured correctly and able to reach each other before you see anything. Any one of them misconfigured produces the same symptom: an empty map with no error message.
• HTTPS is not optional for mobile. Modern iOS and Android apps refuse to send location data to plain HTTP endpoints. You need TLS, which means a domain and a working reverse proxy before the mobile apps will connect.
• MQTT vs HTTP mode. OwnTracks Recorder supports both protocols. Your choice affects how you configure the mobile apps, whether you need a Mosquitto broker, and how the Recorder is exposed. The Frontend documentation doesn’t address this — you’ll be reading the Recorder docs separately.
• CORS configuration. If the Frontend and Recorder are on different ports or subdomains, you’ll run into CORS errors. The README includes a corsProxy.js script for development, but production setups need proper reverse proxy headers [1].

Realistic time estimate: A technically comfortable user who has run Docker Compose before: 2–4 hours for the full stack including TLS and mobile app configuration. Someone new to self-hosting: budget a full day and follow a community guide that covers the complete OwnTracks stack, not just the Frontend.

---

Pros and Cons

Pros

• MIT license. You can fork it, modify it, embed it, or resell it. No restrictions [1].
• Heatmaps and history in one interface. The core reason to use this over the stock Recorder UI. Visualizing movement patterns over weeks or months is genuinely useful and not available out of the box with the Recorder’s built-in pages [1].
• Zero-configuration default. If the Recorder API is at the same host as the Frontend, you don’t need to touch config.js at all [1].
• Docker-native. Pre-built image with environment variable configuration means no build step in production [1].
• Active CI and releases. Build, test, and lint pipelines running on every commit. 35 releases shipped. Not abandoned [1].
• Data sovereignty. Location data never leaves your infrastructure — no third-party company gets a copy of your movement history.
• Accurate battery and speed data. When the mobile app reports it, the Frontend surfaces it in the popup — details that commercial apps either hide or upsell [1].

Cons

• Not standalone. Three-component dependency (mobile app + Recorder + Frontend) before you see any data. This is an inherent limitation of the architecture, not a fixable bug [1].
• Small community. 528 stars and 65 forks is modest. Bug reports and community guides are thin compared to more popular self-hosted tools. If something breaks in an unusual configuration, you may be debugging it yourself [1].
• No authentication layer. The Frontend doesn’t manage authentication — it connects directly to the Recorder API. Access control is your responsibility via your reverse proxy. This is the right architecture but easy to misconfigure, leaving the map publicly accessible.
• No mobile-responsive design documented. It’s a Vue SPA with a map — workable on mobile browsers but clearly designed for desktop use.
• HTTPS is mandatory in practice (not the Frontend’s fault, but part of the real setup cost). Plain HTTP mode is effectively development-only.
• No multi-tenant or sharing features. This is a personal/family tool. There’s no access control within the Frontend itself — everyone who can reach the URL sees all devices.

---

Who should use this / who shouldn’t

Use OwnTracks Frontend if:

• You’re already running OwnTracks Recorder and want a better web UI than the bundled pages.
• You’re planning a full self-hosted location tracking stack and want an MIT-licensed frontend that works with Docker Compose.
• You want heatmaps, date-range history, and device filtering in a single browser interface.
• Privacy and data sovereignty matter more to you than convenience — you want your location data on your server, full stop.

Skip it (use the stock Recorder UI) if:

• You only need basic “where is this device now” functionality and don’t care about heatmaps or history visualization.
• You want to minimize the number of moving parts in your stack.

Skip OwnTracks entirely (use Life360 or Find My) if:

• You’ve never run a Docker container and don’t have a technical person to set this up.
• You need geofence alerts and notifications — OwnTracks Recorder supports regions, but the alert pipeline (MQTT → notification service) requires additional setup beyond the Frontend.
• You need more than 2–3 family members tracked without significant effort — OwnTracks scales fine technically, but the per-device configuration overhead is manual.

Skip OwnTracks entirely (use Traccar) if:

• You need multi-user access control, a mobile-friendly dashboard, vehicle tracking, and an active support community. Traccar is a more complete platform with a built-in web interface that doesn’t require a separate Frontend component.

---

Alternatives worth considering

• Traccar — the most complete open-source location tracking platform. Supports GPS hardware devices, not just smartphones. Has a built-in web interface, user management, and geofence notifications. More complex to set up but more feature-complete.
• PhoneTrack (Nextcloud app) — if you’re already running Nextcloud, PhoneTrack adds location tracking as an app with no additional infrastructure. Less flexible than OwnTracks but zero marginal server cost.
• Dawarich — newer self-hosted location history tool with a focus on timeline visualization and export. Less mature but gaining attention in the r/selfhosted community as a Google Maps Timeline alternative.
• Overland — iOS app (from Craig Mod) with a companion server. Narrower scope than OwnTracks but simpler to configure for iPhone-only households.
• Life360 — commercial, family-focused, easy to set up, location data leaves your control. The incumbent this whole category is replacing.

For most non-technical users building a family location stack from scratch, the realistic shortlist is OwnTracks (Recorder + Frontend) vs Traccar. OwnTracks is better for smartphone-only households that want maximum privacy. Traccar is better if you need a polished UI, notifications, and multi-user access control out of the box.

---

Bottom line

OwnTracks Frontend does exactly what it says: it’s a better web interface for OwnTracks Recorder. The heatmaps, location history, date filtering, and device-specific views are real improvements over the stock pages, and the Docker setup is clean. The honest caveat is that you’re buying a frontend component for a three-part stack, not a complete solution. If you’ve already committed to the OwnTracks ecosystem for privacy reasons, this Frontend makes the data meaningfully more usable. If you haven’t started yet, budget the setup time for the full stack and understand that the mobile app configuration and TLS setup are where most of the friction actually lives — not in the Frontend itself.

If the stack setup is the blocker, that’s exactly what upready.dev deploys for clients. One-time fee, done, you own the infrastructure.

---

Sources

1. OwnTracks Frontend — GitHub Repository and README. https://github.com/owntracks/frontend

Primary sources consulted:

• GitHub repository (owntracks/frontend): https://github.com/owntracks/frontend — 528 stars, 65 forks, MIT license, 322 commits, 35 releases
• Docker Hub image (owntracks/frontend): https://hub.docker.com/r/owntracks/frontend
• OwnTracks Recorder (backend dependency): https://github.com/owntracks/recorder

Note: Third-party review articles were not available for this tool at time of writing. This review is based on first-party documentation and repository data.