Hi there,
recently there has been a post here about Colota and thought you might be interested in a short summary about Colota.
I am tracking my position since several years now mainly with Owntracks (and now Colota) and a simple postgres DB/table.
I am a fan of the indieweb and eat what you cook and with already some million location points collected I recognized some pattern in existing GPS trackers I wasn’t happy about:
- Battery consumption
- Duplicate points while staying in the same location for a long time
So I decided to build my own GPS tracker and called it Custom Location Tracker.
Improved battery consumption should come from disabling GPS entirely in so called “geofences” which are basically circles you draw on a map in the app. With GPS disabled in these you also won’t get duplicate points while staying at e.g. home or work.
The app is still quite new (actively developed since early 2026) but has already quite a lot of features which basically all came from user feedback. E.g.:
- Automatic Tracking profiles which apply different tracking settings while e.g. being connected to Android Auto, moving slower than 6km/h or while the phone is currently charging.
- The app works fully offline (map will not be visible then) but you can predownload map tiles from a tile server I selfhost or use your own tile server.
- You can define how locations are synced to your backend. E.g. only for a specific Wi-Fi SSID every 15min, once a day or with every location update.
Overall the app’s focus should move to be a mobile location history app. So basically Google Timeline in a mobile app which also supports selfhosted backends (as backup).
The app is fully open-source AGPL-3.0, has no ads, analytics or telemetry and only sends data to your own server (if you want to).
You can download two versions.
- Google Play store which uses Fused Location Provider and therefore uses Google APIs. Also works with the sandboxed version by GrapheneOS and microG.
- FOSS version which uses Android’s native GPS provider with a network location fallback. Available on IzzyOnDroid and hopefully someday on F-droid.
Both can be also downloaded directly from the repo.
Hi mxdcodes. I have been using your app for the past month in a sort of testing phase with Darawich. I have used GPS Logger and Reitti since October last year, which is still running, but Colota offers a lot more exciting possibilities of data collection and so I’ll probably switch across pretty soon. I got hit by the bug a while back of it stopping once entering a geofence, but I saw that got fixed promptly so thanks for all of this.
I love all that you and others who code for the (wider) selfhosted community offer, so let me say that for every person criticizing your app and all the effort you have put in, there are hopefully 1000x more of us who are truly grateful for what you and others do. I find it odd that people who are concerned about having their location history hacked by someone are actually wanting to record their location history in the first place. Seems the obvious answer is to… not track your location history with ANY app.
Keep up the good work!
Thank you, really appreciate it! Glad to hear Colota is working well with Dawarich for you so far. Feedback and criticism are always welcome. Most of it has led to real improvements in the app. I think a casual forum thread is probably just not the best setting for deep technical discussions, where context shifts quickly, everyone has a different background and nuance gets lost.
I’ve being using offline location tracking using a different app for some time now. This looked like a pretty elegant alternative, so I decided to give it a shot!
The app looks great, and very well thought through. The automation features really appeal to me (disabling tracking at home, automatically changing profiles, etc.)
One thing I wish it had was the ability to associate vehicles with trips (potentially, automatically, based on Bluetooth connections or other triggers). I like to track the category for each of my trips (car, bike, train, walk), as well as the specific vehicle (when applicable).
I haven’t tested too much yet, but it looks like you already have pretty robust trip tracking. It would be awesome if I could create a list of vehicles with types, and select a vehicle when starting a trip, or have it automatically set when connecting to a Bluetooth device.
In any case, this app looks great, and I appreciate the effort you’re putting into an open source project like this.
Thanks for the kind words! Vehicle/trip categories (car, bike, train, walk) + per-vehicle tracking is a great idea and fits well with the profile concept. Personally, I also want to skip other (activity) tracking apps which is the reason I also would love to have these features. Added the feature requests to the backlog. Thanks for taking your time trying out the app and giving feedback!
Why a dedicated backup server instead of just backing up to a local file that can then be backed up to a service of choice?
Also for profiles, it would make more sense to use Bluetooth to detect a vehicle or WiFi to detect when you’re home vs. Geofencing or Android Auto or speed. How can it tell when you leave the geofence if the GPS is off?
Probably phrased that wrong. There is no backup server. Users can create and add one if they like.
Colota offers out of the box file export (csv,geojson, gpx and kml) and supports hive_partitioning via variables in the endpoint (https://colota.app/docs/configuration/server-settings#url-variables).
Colota already uses WiFi for home detection (WiFi pause in geofence zones) and Android Auto/car mode for vehicle profiles.
How can it tell when you leave the geofence if the GPS is off?
GPS is only turned off by being connected to a WiFi or being motionless (or both) while being in a geozone. When wifi disconnects or/and motion is recognized the GPS starts again.
Bluetooth detection is the one thing that doesn’t exist. It could be a useful addition. I will note that. Thank you for the feedback!
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters CA (SSL) Certificate Authority HA Home Assistant automation software ~ High Availability HTTP Hypertext Transfer Protocol, the Web HTTPS HTTP over SSL IP Internet Protocol SSH Secure Shell for remote terminal access SSL Secure Sockets Layer, for transparent encryption TLS Transport Layer Security, supersedes SSL VPN Virtual Private Network VPS Virtual Private Server (opposed to shared hosting)
10 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.
[Thread #235 for this comm, first seen 12th Apr 2026, 12:40] [FAQ] [Full list] [Contact] [Source code]
Thank you for sharing. Is this information encrypted? Doesn’t seem safe to use without that…
All phones are already disk encrypted these days. If you want disk encryption on your PC, you should enable it. Otherwise, it’s the responsibility of whatever backend you choose to handle encryption over the network.
No one is talking about a phone or a PC, we’re talking about a server.
Also phones and PCs are only encrypted at rest.
Who is “we”? I’m responding to your top level comment. You just asked the creator of an exclusively client-side app whether they support encryption. Not only is it reasonable for me to assume you mean client side encryption, it’s unreasonable for you to ask for server side encryption, because there is no server. It’s a BYOBackend situation.
Now if you’re asking for client-side encryption, something like Keepass where the file itself is encrypted, you have to use some form of auth to decrypt it on use, and you can store this file using whatever backend you want, that’s perfectly reasonable. I would still consider that encrypted at rest, but at least you could maybe separate encrypted reads from writes and limit the attack surface in the event of a breach.
You just asked the creator of an exclusively client-side app whether they support encryption.
Client-side encryption is not a novel concept.
something like Keepass where the file itself is encrypted, you have to use some form of auth to decrypt it on use
That’s significantly more complicated and time-consuming.
Lol I don’t know what you want man, i didn’t realize this was one of those “digging my heels in because I don’t know how to be wrong” threads. I’ll let you do your thing, peace.
I don’t know what you want man
I honestly don’t know how to be more clear about this. It’s not complicated. I want client-side encryption, man.
i didn’t realize this was one of those “digging my heels in because I don’t know how to be wrong” threads
LOL I didn’t know that either, but here you are!
I absolutely agree with you. Such private data should be End-To-End-Encrypted.
I also agree with you both that location data is definitely personal data that should be protected. However, Colota stores data only on your own device and it’s never sent anywhere unless you configure a server and that server is out of Colota’s reach. End-To-End-Encryption doesn’t apply here since Colota is just one endpoint sending to the user’s own server. There’s no third party to encrypt against.
Colota is also meant to be an app which supports several “Google Timeline” alternatives like Dawarich, Reitti, Geopulse, etc. All these backends would have to support the same decryption which Colota offers, which is not realistic. You can also specify that data is only sent via an active VPN connection or just use it offline and use the built in file export as e.g. geojson.
Also Colota is a free and open source project. You can review the full source code to verify how your data is handled.
There’s no third party to encrypt against.
Encryption does not exist for third parties. It exists to protect sensitive data from malicious or state actors who might hack your server and steal the information for various purposes. Here in the US law enforcement is free to hack and steal and demand whatever they want.
All these backends would have to support the same decryption which Colota offers, which is not realistic.
I would prefer single-party encryption vs. integration, personally. Could make it optional.
I appreciate your contributions but for me personally this is a dealbreaker.
Encryption does not exist for third parties.
E2E encryption is specifically designed for the third-party problem. Encrypting so a middleman can’t read your data.
It exists to protect sensitive data from malicious or state actors who might hack your server and steal the information for various purposes
If a server gets hacked where a user sent data from Colota there is nothing the app can do about it or to prevent it. Also you can create a backend which encrypts the data. Again: Colota does not offer a backend.
Here in the US law enforcement is free to hack and steal and demand whatever they want
I don’t think it’s the job of an Android app to protect a server from government hacking attacks.
I would prefer single-party encryption vs. integration, personally. Could make it optional.
I understand the concern. The tradeoff is that backends like Dawarich or GeoPulse need to read the coordinates to build timelines, detect trips, display maps, etc. Encrypted blobs would make the server a simple backup at which point the local auto-export to Syncthing/Nextcloud achieves the same thing without the complexity. For pure backup, the offline + file export workflow already covers that use case. Also the app is offline-first. There is no server needed unless the user specifically configures that.
I appreciate your contributions but for me personally this is a dealbreaker.
Fair enough, thanks for the feedback.
If a server gets hacked where a user sent data from Colota there is nothing the app can do about it or to prevent it
It can’t prevent the hack, it absolutely can protect the data, and make it useless. That’s the entire purpose of encryption.
I don’t think it’s the job of an Android app to protect a server from government hacking attacks.
Again, it’s not supposed to.
Also the app is offline-first. There is no server needed unless the user specifically configures that.
The server is needed for the same reason a server is needed for anything: to back up the data.
If you don’t want to implement it, that’s fine, I respect your decision, but there’s no reason to come here pretending not to understand its purpose.
It’s not that I don’t want. I can’t implement it because I don’t offer a server. You would have to address this to the backend developers (Dawarich, GeoPulse or even yourself) who actually store the data.
but there’s no reason to come here pretending not to understand its purpose.
I am understanding your point, but apparently you are not understanding mine which is the actual use case of the app and it’s workflows and therefore make it look like it would miss basic security patterns. The whole “location history” ecosystem stores plaintext coordinates.
It’s not that I don’t want. I can’t implement it because I don’t offer a server.
You don’t have to. You just have the app encrypt the data before it’s backed up and exported.
you are not understanding mine which is the actual use case of the app
I understand the usecase but you’re acting like you don’t understand the purpose of encryption, for some reason suggesting that it’s supposed to prevent hacking, when that is not at all what it does.
If the target server is compromised or taken by LEA the data is gone.
Laying the responsibility into the hands of the user is not ok for such an data aggregating service. Such highly critical, private and intime data should be protected and secure by default.
Not even transport encryption is enforced in the project. At first glance, http is allowed on local connections?!? Generate a self signed SSL cert on start and pin it in the app. Easy.
It is no excuse that other services do not follow these state of the art protection measures.
It is no excuse that other services do not follow these state of the art protection measures.
Most projects in the self-hosted space put the load of transport security on the user or another system, including big ones like Immich.
Not sure why you’ve chosen to be indignant about this particular implementation.
Not sure why you’ve chosen to be indignant about this particular implementation.
We are talking about a tracking App. Most selfhosted projects do not store such private data. You may can mage the argument for immich but only for ppl who take a picture every 5 min.
Most selfhosted projects do not store such private data.
That is patently not true, in the self-hosted space or otherwise.
If you want to take some kind of the security stance on pii or other personal data, you may want to take a look at the app’s workflow first before making declarations of “inadequate security”. There are other considerations than simply slapping a self-signed cert on data in transit (or at rest, for that matter). URL encoding, secrets management, api structure, etc.
If you want to architect the security of your data using this app, it is much easier to simply encapsulate or encrypt the transport yourself. A VPN would be fine. An authentication proxy would be another.
Ultimately, your comments on security here need more and better context to meet a reasonable threshold of confronting the dev on it.
In security and development there is a statement, called “secure by default”. That means the default settings are secure. This would encapsulate something like enforced Transport encryption.
Does this mean that the config can not be changed to fit the thread model? No.
