Colota sends your location to a server you control

The server is yours, and the app says so first

Colota is described as a self-hosted GPS tracking app for Android, and the sentence that follows sets the whole product apart from a typical location service. Colota sends your location to your own server over HTTP(S). It works offline, supports geofencing, and has no analytics or telemetry. The privacy line is stated with equal bluntness, no analytics, no telemetry, no third-party SDKs, open source under AGPL-3.0. For a location tracker that is an unusual set of commitments, because the commercially interesting part of location data is usually exactly the aggregate and the telemetry. Colota declines that and sends the raw feed to infrastructure you run. The project is published under the name com.Colota and is reachable from four places, Google Play, F-Droid, IzzyOnDroid and the APK attached to GitHub releases, so the same build is available whether or not you want Google's distribution. The homepage is colota.app, and the documentation there covers configuration, server integration, geofencing, data export, an API reference, battery optimization, troubleshooting and development setup.

Nine backends and the open protocol behind them

The list of compatible servers is the most useful line in the feature list, because it tells you the app is not tied to one ecosystem. It works with Dawarich, GeoPulse, Home Assistant, OwnTracks, Overland, PhoneTrack, Reitti, Traccar or any custom backend. Several of those names are worth reading for what they imply. Traccar and OwnTracks are long established open tracking servers with their own clients, so Colota is one more way to feed them. Home Assistant is the common case for a household that already runs it. Dawarich and GeoPulse are the newer dedicated timeline products, and their presence tells you the app was built to feed a timeline rather than only a dot on a map. The final entry, any custom backend, is the one that matters most for a self-hosted design, because it means the app is written against a documented API rather than against one server's quirks. The documentation site covers server integration guides for each of those named backends plus custom ones, and there is a separate API reference section, which together suggest that a new backend is a documented contract rather than an exercise in reverse engineering.

Offline means export, and export has four formats

The offline behaviour is specific rather than vague. Colota is fully functional without a server, and you export as CSV, GeoJSON, GPX or KML. That is a meaningful list because each format has a different audience, with GeoJSON and KML the ones a mapping tool or a web map will read, GPX the one a GPS device or a track editor expects, and CSV the one you can open in a spreadsheet or a database. The recording side has the corresponding set of features. There is location history with daily summaries, trip segmentation with manual merge and split, per-point notes, and a calendar with activity dots and per-trip export. Manual merge and split on trip segmentation is worth calling out, because automatic trip detection is where most trackers are least reliable, and giving the user a merge and split control means a bad boundary is a correction rather than a lost trip. Import runs in the same direction, bringing in existing tracks from GeoJSON, Google Timeline, GPX, KML or CSV, so the app can take over from whatever you used before rather than starting empty.

Profiles and sync modes are the settings that matter day to day

Tracking profiles are the feature that makes this usable rather than merely private. The app automatically adjusts the GPS interval, the distance filter and the sync settings based on conditions like charging, Android Auto, Wi-Fi, a Bluetooth device, speed or stationary detection. The reasoning is straightforward once stated, because the two things that drain a phone are a chatty GPS radio and a chatty network radio, and both of those change with what you are doing. A phone plugged into a car charging can afford a tight interval, a phone sitting still on a desk should not be polling at all, and a Bluetooth connection to a car headset is a good enough hint to change behaviour without a manual toggle. Sync itself has three modes, instant, batch or offline, and you can restrict it to Wi-Fi, to a specific SSID or to a VPN. That last option is a detail that tells you the author has thought about metered and metered-by-proxy users, which is the sort of user a self-hosted location tool attracts. Scheduled export adds automatic daily, weekly or monthly exports to a local directory with file retention management, so the archive grows on a schedule and old files are cleaned up without a script.

Getting it onto the phone, and building it yourself

The quick start is five steps and one of them is the one people miss. Install from Google Play, F-Droid, IzzyOnDroid or the GitHub releases APK. Grant location permissions, precise and all the time. Grant the notification permission, which is optional, though on Android 13 and later refusing it hides the status notification. Disable battery optimization for Colota. Then press Start Tracking. That fourth step is not optional in practice, because Android's battery optimization will stop a background tracking service and the app will simply stop recording. The README also mentions reliable tracking with a foreground service, auto-start on boot and exponential backoff retry, which is the same problem answered in code rather than in user settings, though the two are complementary rather than substitutes. Building from source needs Node.js 24, the version pinned in the .nvmrc, the Android SDK and JDK 17 or newer, and the build is a workspace with a shared package:

git clone https://github.com/dietrichmax/colota.git
cd colota
npm ci
npm run build -w @colota/shared
cd apps/mobile/android
./gradlew assembleGmsRelease    # Google Play variant
./gradlew assembleFossRelease   # F-Droid variant (no Google Play Services)

The two Gradle targets are the interesting part of that sequence, because the F-Droid variant is built without Google Play Services, which is a different build of the same app rather than a repackaged one. The root package.json shows the workspace layout with apps/* and packages/*, and the root scripts are all delegations, with lint, test and clean running across workspaces with --if-present, formatting through prettier over js, jsx, ts, tsx, json and md, and two screenshot scripts and an icon generator that are clearly for store submissions rather than for the app itself.

Setup shortcuts, mutual TLS and the smaller details

The remaining items are the ones that separate a personal tool from a hobby project. Quick Setup configures devices through colota://setup deep links or QR codes, which is what makes provisioning several phones or tablets practical rather than a typing exercise. Authentication supports Basic Auth, Bearer Token or custom headers, and there is optional mutual TLS with a PKCS12 client certificate held in the Android Keystore, which matters if your backend is behind a client certificate authenticating proxy. App shortcuts let you long-press the app icon to start or stop tracking straight from the home screen, and the README notes the compatibility with automation apps like Tasker and Samsung Routines. Geofencing is described as pause zones that automatically stop recording locations, which is the behaviour that keeps a tracker useful, since a location history filled with hours spent at home is mostly noise. Encrypted Backup covers the other half of the problem, a single password-encrypted archive of all data, locations, settings, geofences and credentials, for migration or offsite storage. The privacy stance extends to the app itself, with full light and dark theme support and English, Spanish and Simplified Chinese, with a documentation page for translation help.

Editorial conclusion

Adopt Colota when you want location history on infrastructure you control, when you are willing to run one of the supported backends or point it at your own, and when you accept that the app needs precise always-on location permission. Do not adopt it if you want a hosted service that needs no setup, because the whole premise is that the server is yours. Verify first which of the listed backends your server speaks, that your HTTP or HTTPS endpoint accepts the authentication you intend to use, and that the Android version in use still permits the foreground service behaviour the app depends on.

Frequently asked questions

Official sources

1. dietrichmax/colota on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases