AdventureLog: a self-hosted travel tracker built on Django and SvelteKit
Self-hostable travel tracker and trip planner.
At a glance
- What is it?
- AdventureLog combines location logging, multi-day trip itineraries and country-level travel stats in one self-hosted app. The repository shows a Django REST backend, a SvelteKit frontend and an integrations layer for Immich, Strava, Endurain, Wanderer and Google Maps. The main question for a homelab operator is whether the install and backup path is worth it for a personal travel log.
- Who is it for?
- AdventureLog fits someone who already runs a homelab, wants travel history and itineraries in one place, and is willing to keep a Django plus Postgres stack alive. It is the wrong choice if you want a hosted service with zero maintenance, or if you only need a map of visited countries, since the country-tracking part alone does not justify the full stack.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Svelte, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap AdventureLog fills between a photo library and a spreadsheet
Most travel records end up split across tools. Photos sit in a media library, flight confirmations sit in email, and the list of countries you have actually set foot in lives in a spreadsheet or in your head. AdventureLog's README frames the project as a single place for the three activities it names: logging where you have been, planning what comes next, and seeing the whole thing on one map. That combination is the product. The target user is a self-hoster who already runs other services and wants travel data on their own hardware rather than in a vendor account. The feature table lists locations and visits with dates, notes, photos, categories and multi-visit history, trip itineraries with flights, lodging, checklists and calendar views, a world travel book covering countries, regions and cities, and trail or activity records with GPX tracks. There is also a collaboration layer: locations and itineraries can be shared through public links or with other users who get edit access. That last point matters more than it first appears, because travel planning is usually a shared activity, and a single-user app would have been a much smaller proposition.
Django REST behind SvelteKit, with integrations as the data entry path
The repository topics name the stack directly: django, django-rest-framework, allauth, sveltekit, tailwindcss and daisyui, packaged with docker, dockerfile and nginx. So the shape is a Django API with authentication handled through django-allauth, and a SvelteKit frontend that talks to it. The README's security row lists MFA, API keys and social auth including Google, GitHub and Authelia, which is consistent with allauth sitting in the middle of the login flow. The integration table is where the data flow becomes interesting. Immich is used to link photos from a self-hosted media library rather than uploading images into AdventureLog itself. Strava and Endurain are import sources for activities with GPX tracks and stats. Wanderer attaches trails with distance and elevation data. Google Maps provides geocoding and location search. Read together, the design assumes you already run adjacent self-hosted services and treats AdventureLog as the index over them. That is a reasonable architecture for a homelab, but it also means the app is most useful to people who are already inside that ecosystem. A user with no Immich instance and no activity tracker gets a manual entry tool, which is a different and much smaller product.
What the README actually tells you about installing it
The quick start section is explicit that the fastest path is one container on one port, and it opens a curl command. The README text supplied here cuts off mid-command at the line beginning with curl, so the full invocation cannot be reproduced from this material. The honest instruction is to take it from the Getting Started page at adventurelog.app/docs/install/getting_started.html, which the README points to for Docker, homelab NAS, Kubernetes and reverse proxy setups. What can be confirmed from the repository metadata is the packaging: the project ships a Dockerfile and lists nginx among its topics, so a reverse proxy is part of the expected deployment rather than an afterthought. The configuration surface is documented per integration, with separate pages for Immich, Strava, Endurain, Wanderer and Google Maps, which implies credentials and endpoints for each are set through configuration rather than hardcoded. Beyond that, the README does not list environment variable names or a compose file in the text available, so anyone planning a deployment should read the install documentation before assuming a single docker run covers it.
Where the self-hosted model costs you something
The trade-off table in the README compares AdventureLog with closed travel apps on ownership, cost, privacy, customization and scope. Ownership is the real argument and it holds. The cost side is where the table is thinner than it looks. Free to self-host means free of licence fees, not free of operational work. You are running a Django application, a database and a reverse proxy, and you are responsible for backups, upgrades and TLS. The release cadence visible in the metadata makes that concrete: v0.12.0 in February 2026, v0.12.1 in May 2026, v0.13.0 in August 2026. Three releases in roughly six months is a healthy pace, and it also means an instance left unattended drifts. The failure mode that matters most for this class of app is not a crash, it is data loss. A travel log accumulates years of entries, photos references and trip plans, and none of that is recoverable from anywhere else if your volume dies. The README does not describe a backup mechanism in the material available, so backup is on you. A second limitation is scope creep in the opposite direction: the app covers locations, itineraries, trails, activities, countries and regions, and each of those has its own screens and data model. If you only want to color in a world map, this is a large amount of software for that job.
How it differs from a plain visited-countries tracker
The obvious alternative for the world-map use case is a dedicated country tracker, the kind that stores a list of ISO country codes and renders a choropleth. The difference in approach is not cosmetic. A country tracker has one entity, the country, and one state, visited or not. AdventureLog's model is location-centric: a location carries coordinates, dates, notes, photos, categories, tags and a multi-visit history, and countries and regions are aggregations over those locations. That is why the README can offer regions as a drill-down into states, provinces and territories, and why trip statistics can break down cost and geography per trip. The cost of that richer model is that entering data takes more effort, and the value depends on actually recording visits rather than ticking boxes. If your travel history is already a list of countries and you have no intention of logging individual places, a country tracker will do the job with far less infrastructure. AdventureLog earns its keep when the itinerary and the per-location record are the point, not the country count.
Licence and the upgrade path you are signing up for
There is a discrepancy worth flagging before anyone plans around it. The repository metadata reports the licence as NOASSERTION, which means the automated classifier could not match the licence file to a known identifier. The README displays a GPL-3.0 badge and links to a LICENSE file. Those two signals disagree, and the resolution is to open the LICENSE file and read it rather than trusting either the badge or the metadata. This is not a legal opinion, just an observation about what the material shows. On maintenance, the version history suggests the project is moving. The release names include a codename, with v0.13.0 labelled Acadia, which is a convention some projects adopt once they consider releases worth naming. The practical implication for an operator is that upgrading between minor versions is a real task, not a no-op, and the release notes for each version are the only place that will tell you whether a migration runs. Pinning to a specific tag and reading the notes before moving is the low-effort way to avoid a surprise.
Who should run this, and what to check before you do
AdventureLog is a good fit for someone who already self-hosts, has an Immich library or an activity tracker feeding it data, and wants travel history and forward planning in one interface they control. The collaboration features make it usable for a couple or a small group planning trips together, which is a use case most homelab apps do not cover. It is a poor fit for anyone who wants zero maintenance, and it is overkill for someone whose only goal is a map of countries visited. The middle case, a solo traveler who wants itineraries and per-place notes but has no other self-hosted services, is genuinely ambiguous: the app works, but the integration layer that gives it an advantage sits unused. Before deploying, verify the full install command on the Getting Started page, read the LICENSE file to settle the GPL-3.0 versus NOASSERTION question, and check the release notes for v0.13.0 to see whether the upgrade from v0.12.x carries a database migration. Those three checks take a few minutes and cover the decisions that are hard to reverse.
Editorial conclusion
AdventureLog fits someone who already runs a homelab, wants travel history and itineraries in one place, and is willing to keep a Django plus Postgres stack alive. It is the wrong choice if you want a hosted service with zero maintenance, or if you only need a map of visited countries, since the country-tracking part alone does not justify the full stack. Before adopting it, check three things: the exact install command on the Getting Started page rather than the truncated snippet in the README, the licence file itself because the repository metadata reports NOASSERTION while the README badge says GPL-3.0, and the migration notes for the upgrade path between the v0.12 and v0.13 release lines.
Community notes