GpsTracker is a self-hosted tracker you can point your own phones at

Three components, and a project that has been running since 2007

GPS Tracker is described as a complete GPS tracking system that lets you track mobile devices in real time using Google or Open Street Maps and other map providers, and the documentation says the project has been actively maintained since 2007 with version 7 representing a complete rewrite of the core components. The architecture is three parts, and the split is the obvious one. The mobile clients are native apps for iOS and Android that capture location data. The server is a PHP and JavaScript backend that receives, stores and processes the location updates. And the web interface is a responsive dashboard for viewing real-time and historical tracking data. The live demo is linked from the README, and the project is archived on Zenodo with a DOI, which is the sort of thing a long-lived open source project accumulates so that citations resolve. The features list covers the expected ground, with real-time tracking on configurable update intervals, background tracking on the device, several map providers, route history and playback, distance, speed and battery level tracking, and support for multiple devices and users.

What version 7 actually rewrote

The release notes for version 7 are worth reading closely, because a rewrite that is described in a single line is usually a rewrite of something smaller than the reader assumes. Here it is spelled out, and the three components were each replaced. The PHP and JavaScript server was modernised with clean architecture and a responsive design. The Android client was completely rewritten in Kotlin with an MVVM architecture. And the iOS client is a new Swift implementation with SwiftUI and an MVVM architecture. The documentation also says the rewrite was done with the assistance of Google Gemini Pro 2.5, which is a useful disclosure, and the release tag itself says gemini-2.5-pro code update, so a reader knows the nature of the code they are about to run. The claim that all three components have production quality code with comprehensive inline documentation is the maintainer's, and the way to judge it is to read the code rather than the claim.

Installing the server is five steps with a fallback for shared hosting

The server requirements are PHP 8.1 or newer for version 7, where earlier versions supported 7.4, a MySQL, PostgreSQL or SQLite database, Apache or Nginx, and Composer. The Apache route goes like this. Clone the repository, copy the server files into your web directory, install the PHP dependencies, set permissions, and configure the environment:

git clone https://github.com/nickfox/GpsTracker.git
cp -r GpsTracker/servers/php/* /var/www/html/gpstracker/
cd /var/www/html/gpstracker/
composer install --no-dev --optimize-autoloader
chmod -R 755 /var/www/html/gpstracker/
chown -R www-data:www-data /var/www/html/gpstracker/

The two Composer flags are explained, with `--no-dev` skipping the development dependencies such as PHPUnit and PHPStan for production, and `--optimize-autoloader` improving performance. The environment step is a copy of `.env.example` to `.env` and an edit of that file, and the documentation lists what matters in it, the database connection, the map provider which is OpenStreetMap by default or Google Maps with an API key, application settings such as debug mode and timezone, and the measurement units in miles or kilometres. The fallback for hosts without shell access is unusually practical, run `composer install --no-dev` locally and upload the generated `vendor/` folder along with the rest of the files.

The schema is the contract between the phone and the server

The database step is where the system is easiest to understand, because the tables are small and the columns map directly onto what a phone reports. SQLite creates its own database file in the `sqlite` directory, while MySQL and PostgreSQL need the tables created by hand, and the guide prints them. The locations table holds a device identifier, latitude and longitude with enough decimals to be a real coordinate, speed, heading, altitude, accuracy, the event time, the battery level, the app version and a creation timestamp. The routes table holds a device identifier, a route name, a colour, start and end times, a distance and its own timestamps with an update trigger. Two details are worth noticing. The `locations` table is an event log, not a current state table, so the history comes for free and playback is a query rather than a feature you build. And the columns are plain, which means a team that wants to add a geofence or a trip detector can write it in SQL against the same table the map reads.

Two native clients, each pointed at your server by hand

The mobile clients are native applications you build yourself, and both need the server address edited in the source before they will do anything. The Android client needs Android Studio 4.0 or newer and the Android SDK at 21 or newer, you open the existing project at `GpsTracker/phoneClients/android-kotlin`, and you set the URL in `Constants.kt`:

const val SERVER_URL = "http://your-server.com/gpstracker"

The iOS client needs Xcode 16.2 or newer, iOS 15.0 or newer and Swift 5.8 or newer, you open `GpsTracker/phoneClients/ios-swift/GPSTracker.xcodeproj`, and you set the base URL in `APIService.swift`, which points at the location endpoint. In both cases the address is hardcoded rather than typed into a settings screen, which is the least convenient choice and also the most honest one, since it makes it obvious that the app talks to one server and one server only. The Android instructions note that the app is coming soon to Google Play, and the tracking itself runs in the background with an interval you configure.

Nginx gets a config, and the old parts stay in the tree

The Nginx route reuses the first five steps of the Apache one and then adds a server block, a front controller that falls back to `index.php`, a PHP location block pointing at the PHP-FPM socket for the version you are running, and a rule denying access to `.ht` files, followed by a restart of the service and a return to the database step. The block is a sensible default rather than a production configuration, since it hardcodes the fastcgi socket path and leaves the TLS story to you. Under a heading on legacy components, the documentation lists what is still in the repository but no longer maintained, starting with an ASP.NET backend on SQL Server and a Windows Phone client. That section is worth pausing on, because it tells you the repository carries a decade of history and that only the version 7 parts are alive. The tree itself is small, with `phoneClients/`, `servers/`, a citation file, the licence, the readme and an image, which is a reminder that the bulk of the code is in the two client directories and the PHP server.

The question the software cannot answer for you

A tracker that records the movements of other people is a tool whose usefulness depends entirely on consent, and no installation guide changes that. The project's own framing, tracking your own devices and multiple users, is a family or fleet tool, and the technical design suits that, since the data is in your database and nothing is sent to a third party service unless you configure a hosted map provider. Two practical notes follow from that. First, if you enable a commercial map provider, the tile requests and the coordinates in the URL leave your server, so the privacy story depends on that choice as much as on the code. Second, the tracking is continuous and in the background, so the people being tracked will be walking around with the app running, which is a disclosure and consent question rather than a technical one, and one that varies by jurisdiction. A reviewer should also weigh the size of the surface, since the system accepts location updates over HTTP from the phone, so the server needs authentication before it accepts a route from a device that is not yours.

Editorial conclusion

GpsTracker suits a family, a small fleet or a hobbyist who wants the location history of their own devices on their own server, with no third party account in the middle and a schema simple enough to query directly. It is a poor fit if you need a turnkey product, since the install guide assumes someone with a shell, a web server and a database, and it is a poor fit for tracking anyone who has not agreed to it, since the whole system records other people's movements. Before you deploy it, check three things: the PHP version, since version 7 raised the floor to 8.1 from 7.4, the map provider, since OpenStreetMap is the default and Google Maps needs an API key, and the authorisation of the people being tracked, which is a question the software cannot answer for you.

Frequently asked questions

Official sources

1. License: MIT
2. nickfox/GpsTracker on GitHub
3. Project website
4. README
5. Releases