The most valuable dataset most people hand over in a given year is not their photos or their messages, it is the travel itinerary, because a complete one tells a stranger where you will be and when, when your house sits empty, which borders you cross and on which passport, what card you pay with, and who is standing next to you while you do it, and the hosted travel apps understood this long before their users did, which is exactly why the first thing every one of them asks for is an account. The account is not there to keep your trips safe, it is there to give the collection a primary key, and once you see the sign-up form as the mechanism that turns scattered confirmation emails into a correlated, monetizable movement history, the entire product category starts to look less like a convenience and more like an arrangement you would never have agreed to in person.
What the account is actually correlating
A single forwarded confirmation email is mostly harmless, a flight number and a date and a record locator, and the travel app’s whole value proposition rests on collecting many of these and stitching them into a timeline, which is a genuinely useful trick and also the precise moment the data becomes dangerous, because the stitching works both ways: the same pipeline that assembles your tidy itinerary assembles a structured record of your movements, your companions, your spending, and your documents, keyed to an email address that ties it to everything else that email address has ever touched. Location history from a maps app is a record of where you have already been, assembled from GPS and Wi-Fi fixes whether you asked for it or not, while an itinerary is testimony, a self-declared, timestamped, forward-looking statement of where a person intends to be, and the industry treats the second kind with considerably less ceremony than the first.
The documents make it worse in a way people rarely price in, because a travel organizer that earns its keep eventually holds passport scans, visa numbers, and card references, and storing those next to a correlated movement history under a vendor account means a single breach produces not a leaked password but a complete identity-and-location package, the kind of artifact that would take a motivated stranger months to assemble by hand and takes the attacker’s query about four seconds. We wrote about the general pattern last week, the way the users table drags in retention obligations and breach blast radius, and travel is where that abstract argument stops being abstract, since the payload behind the account is not a todo list, it is the answer to “where will this person be, alone, in another country, on this date.”
The account does nothing the app needs
Strip the marketing off a hosted travel app and ask what the account technically accomplishes for the person holding the phone, and the honest list is short: it syncs between devices, and it lets the vendor recognize you when you come back, and the second item is for them rather than for you, which leaves sync as the entire user-facing justification, and sync is a transport problem that never required an identity system in the first place. Calendars solved this decades ago with a feed you subscribe to, files solved it with a folder you replicate, and the reason travel apps do not offer “here is a private URL, put it in your calendar client” as the primary sync mechanism is not that the idea is hard, it is that a feed does not create a row in the vendor’s users table, and the row is the asset. The incumbents do ship an iCal export if you dig a few settings screens deep, which rather proves the point, because the feed exists and is simply never the default, and a default feed would not mint a user row.
This is the part where the usual defense arrives, that the account enables the magic features, the automatic email parsing and the live flight-status pushes, and it is worth being precise about what those features actually require, because parsing requires access to your mailbox or the forwarding of every confirmation to an address the vendor controls, and status pushes require a paid upstream data feed, and neither one requires the vendor to hold your identity, your documents, and your history in one correlated store; the account is load-bearing for the business model, not for the feature list, and conflating the two is how a billing and retention mechanism got rebranded as a convenience.
What the model looks like without it
Roamarr is our concrete answer to this, and the interesting part for this argument is not the feature list, which we covered when we shipped it, but the shape the data model takes when the account simply does not exist: the whole app is one container on your own hardware, the owner unlocks the instance with a passphrase that derives the encryption key and is never written to the database volume, sensitive fields sit encrypted at rest, and there is no users table on anyone’s infrastructure to breach, subpoena, or quietly re-scope when the terms of service change. Sharing, the one place a travel app genuinely brushes against other people, becomes a scoped and revocable link that exposes exactly one trip, which is a better design than the invite flow it replaces and one that only exists because there was no account to invite anyone into, the absence of the feature forcing the better feature the way it tends to do.
Sync, the legitimate need, gets handled the old way rather than the account way: the instance is reachable from wherever you choose to expose it, a Tailscale tailnet or a reverse proxy you control, and the itinerary follows you because you carry the server, not because a third party carries a copy of you. The forgotten-passphrase story is the honest sharp edge, since a lost passphrase means the encrypted fields stay encrypted forever, which is the guarantee working as designed and exactly no comfort to the person locked out of their own backup, so the recovery plan is a password manager and the responsibility sits with the person who owns the data, which is where it belonged before the industry convinced everyone that convenience meant custody.
The trade, said plainly
The hosted incumbents do two things a self-hosted organizer does not, automatic confirmation parsing and live status pushes, and we are not going to pretend otherwise, because the pitch for self-hosting turns into a brochure the moment it hides the bill, and the bill here is minutes of manual entry per trip and a glance at the airline’s own app for gate changes. Weighed against that is the ongoing, diffuse cost of the hosted version, paid in a correlated movement history you cannot retract, held under terms you did not negotiate, in a store whose breach notification you will read in the news, and when the trade is stated that plainly the typing stops looking like a burden and starts looking like the price of not being the product.
The modern equivalent of this design is not new at all, it is the same instinct that made people run their own mail servers in 2003, back when “keep your own data on your own box” was ordinary practice rather than a political position, except the tooling finally caught up with the instinct, one container, one volume, one backup job, and the itinerary lives where the traveler lives, which is where it should have been all along, and no account required to keep it there.