In brief: Upgrade to Dawarich 1.14.5 if your instance is reachable from the internet: the maintainers state that versions 1.7.1 through 1.14.4 let anyone create an account through the mobile registration endpoint even when registration is disabled, which is the default. If you cannot upgrade yet, block POST /api/v1/auth/register at the reverse proxy and check Settings → Users. This is a source and documentation review, not a deployment test.

Dawarich 1.14.5 at a glance

what 1.14.5 changes

Dawarich is a self-hostable web application that records and visualises personal location history. The repository describes it as an alternative to Google Timeline. Release 1.14.5 arrived on 13 September 2026, about four months after work on the 1.14 line began. The maintainers frame it mainly as a security release with a short list of feature and reliability fixes attached.

the security fix is the reason to act

According to the release notes, self-hosted instances with email and password registration disabled, which the notes describe as the default, allowed anyone who could reach the instance to create an active account through the mobile app registration endpoint, POST /api/v1/auth/register. The same notes state that a family invitation could be used to register an email address other than the one it was sent to. The maintainers list versions 1.7.1 through 1.14.4 as affected and classify the issue as medium severity under advisory GHSA-x483-3xv3-vp52.

The maintainers give two options. Upgrade to 1.14.5, or block POST /api/v1/auth/register at the reverse proxy if an upgrade is not possible immediately. They also tell operators of internet-reachable instances to check Settings → Users for accounts they do not recognise and delete them. A patch closes the endpoint. It does not establish whether anyone already created an account.

the rest of the release is operational

The remaining entries matter more to whoever carries the pager than to whoever picks the product. As described by the maintainers, 1.14.5:

• bounds the per-email API login throttle even when an attacker rotates source IPs, by counting application/json request bodies;
• makes API sign-in ignore leading and trailing spaces in an email address;
• falls back to the default port when OIDC_PORT is blank, non-numeric, or out of range;
• stops sending SMTP credentials when SMTP_AUTHENTICATION=none and a username is set;
• lets GPX imports continue past recoverable XML errors and OwnTracks .rec imports skip malformed lines instead of aborting;
• stops Google Phone Timeline imports from dropping or reordering points that share identical timestamps;
• keeps the identity of places created by reverse geocoding so re-imports do not duplicate them;
• keeps each tracker’s points on its own track when several tracks share a time window.

These are maintainer descriptions, not independently reproduced results. They still point to where the software was fragile: import parsing, geocoding identity, and background job fan-out.

who should upgrade now, and who can wait

If your instance is reachable from the internet, whether through port forwarding, a public VPS, a tunnel, or a reverse proxy with no allowlist, treat 1.14.5 as a patch to apply, not a maintenance item to schedule. The exposed path is unauthenticated account creation, and the affected range covers a long stretch of releases.

If the instance is reachable only on a home network, the direct exposure is narrower, but it is not zero. The same advisory notes that a family invitation could be used to register a different email address than the one it was sent to, so that path runs through an invitation rather than the open endpoint. Lower urgency does not mean no urgency, and a stale invitation stays live until it is revoked.

If you are still evaluating Dawarich and have not deployed anything, the release is not an argument against the project. It is an argument for deploying 1.14.5 or later and for treating scheduled patch windows as part of adoption.

what to check before you upgrade

1. Take a backup you can actually restore. The project’s own readme tells self-hosters to back up before updates and not to delete original data after importing. If you have never restored the backup, you do not know whether it works.
2. Know your starting point and the size of the jump. Releases 1.14.2 through 1.14.4 include statistics recalculations and index repairs, including recovery from indexes left invalid by interrupted migrations. Moving from a 1.7 or 1.9 release to 1.14.5 is not a like-for-like patch.
3. Re-read the environment variable documentation if you touched mail, OIDC, or SMTP. The 1.14.4 and 1.14.5 notes change OIDC port handling, add SMTP certificate verification, and change what happens when SMTP_AUTHENTICATION=none while a username is set.
4. Audit accounts and invitations. Check Settings → Users on any internet-reachable instance, and review family invitations issued while the bypass was open.
5. Confirm your proxy can enforce the deferral block. If you cannot patch immediately, you need a working rule for POST /api/v1/auth/register and a way to verify it is applied.
6. Check whether your compose file or environment file has drifted. The docker-compose.yml attached to releases 1.14.1 through 1.14.5 carries the same SHA-256 digest, so the released container topology did not change across those tags. Divergence is more likely to sit in your own .env than in the release asset.
7. Separate server problems from client problems. Open issues include one where the Android app cannot connect to a self-hosted instance behind a self-signed certificate, and another where the app shows a current location but records no tracking points. Both were open at review time, and a server-side upgrade may not resolve either.

deployment and maintenance signals

Dawarich shipped five patch releases between 31 August and 13 September 2026. Five releases in two weeks is not a defect in itself. It does show how quickly the codebase moves and how often an operator has to look at it.

The repository’s disclaimer is unusually blunt for a project of this size. It tells self-hosters not to update automatically, warns that the software is under active development with frequent updates, bugs, and breaking changes, and tells them to back up before every upgrade. Read that as the maintainers setting expectations, not marketing copy.

Releases are tagged by a single maintainer account, alongside a mix of community pull requests and an automated bot contributor. There were 145 open issues at review time. That is normal for a fast-moving self-hosted project, and it also raises a bus-factor question: if the primary maintainer steps back, patch delivery slows for everyone who self-hosts.

what the repository does not tell you

The reviewed material contains no compatibility matrix, no published performance figures for large point histories, no documented upgrade test results across major versions, and no support commitment. If you plan capacity on top of Dawarich, you are using your own measurements, not the maintainers’.

limitations and alternatives

The licence is AGPL-3.0, not a permissive one. If you intend to modify Dawarich and expose it to third parties over a network, treat the resulting obligations as a question for legal review. A release note cannot settle that.

The readme also points to a hosted offering, Dawarich Cloud, for users who want the instance managed for them. That is the direct alternative to self-hosting: you trade control over the server and data location for someone else owning the upgrade, backup, and incident work. The choice comes down to who is on call.

The last limitation is scope. Dawarich stores continuous location history, supports family sharing, and can pull geodata from photo libraries. Each of those features widens the blast radius of an exposed instance, and the family-sharing consent work visible in the 1.14.3 and 1.14.5 notes suggests the maintainers are still tightening that surface.

who should not self-host dawarich

• Teams with nobody who owns Docker Compose, PostgreSQL, background workers, TLS certificates, and reverse proxy rules as a recurring responsibility.
• Anyone expecting an appliance that updates itself safely. The maintainers explicitly advise against automatic updates.
• Buyers who need a vendor support contract, an uptime commitment, or a documented escalation path before they can rely on the software.
• Organisations handling location data under a policy regime that requires documented access control and audit evidence they cannot produce from the deployment themselves.

evaluation questions to answer before you commit

1. Where do points, photos, and exports physically live, and who can read that storage?
2. Can your reverse proxy enforce an allow or deny rule on one endpoint, and who is authorised to change it during an incident?
3. When did you last restore a backup rather than take one?
4. Which reverse geocoding provider will you use, given that Photon, Geoapify, Nominatim, and LocationIQ all appear in the release notes, and what quota or key is attached to it?
5. Which tracking clients will your users install, chosen from the apps and services the readme lists, and who supports them when points stop arriving?
6. Who receives family invitations, and can those members control sharing of history recorded before they joined?
7. Who is responsible when an upgrade breaks background jobs or recalculates statistics differently than before?

verdict

Dawarich 1.14.5 is a credible, actively developed self-hosted location history tracker, and the registration bypass makes patching the immediate priority for any instance already exposed to the internet. The product looks reasonable for a technically comfortable operator who wants to own their location data and can keep up with backups, patch windows, and post-upgrade checks.

The caveats are the release pace, the concentration of release work in one maintainer account, the unresolved client-side issues, and the project’s own warning against automatic updates. Star count says little about whether you can run that routine. Teams that cannot answer who owns the upgrade should either pick a managed option or make the ownership question explicit before the first release breaks something.

sources

• Freika/dawarich repository: project description, readme, licence, topics, and activity metadata.
• Dawarich 1.14.5 release notes: security advisory summary, workaround, and the full list of changes.
• Advisory GHSA-x483-3xv3-vp52: the self-hosted registration bypass referenced by the maintainers.
• Backup and restore documentation: the procedure the project points self-hosters to before upgrades.
• Issue 2460: Android app connection failure against a self-signed certificate.
• Issue 2536: Android app showing a location but recording no tracking points.

if nobody owns the upgrade path

If you already run a self-hosted instance and the upgrade belongs to everyone and therefore to no one, that gap is the risk. I work on production maintenance and upgrade work for self-hosted Linux services. The practical help is reviewing the deployment as it exists and planning the move to a patched release: the compose files, the environment values that changed in this release, the reverse proxy rules, the version you are really running, and the backup and restore procedure behind it. To start, I would need read access to the stack or repository, a redacted environment file, the reverse proxy configuration, the current backup procedure, and a note on whether the instance is reachable from the internet. I would not begin without a backup that has been restored at least once. You can see the wider scope on the software development services page, or send the specifics through the contact form.