What leaves your phone, and what doesn't.

The short version

• There is no account. Voylen never asks for a name, an email or a sign-in, so there is no profile to leak and no login tying your trips to a person. The one thing our server does derive from you is described under Abuse prevention.
• Your trips live on your phone, in an encrypted database. Photos and documents are encrypted as separate files.
• Nothing is uploaded on its own. There is no background sync.
• Publishing a checklist is the only thing that sends your content, and it sends only the one list you chose.

What Voylen stores on your device

Trips, packing items, the people you travel with, family profiles, photos, documents, notes, bags, saved gear and reusable kits. All of it stays on the phone. The database is encrypted with SQLCipher and photo and document files with AES-256-GCM; the keys are held in the iOS Keychain or the Android Keystore and never leave the device.

Backups are the exception. A backup you export yourself is plain, unencrypted JSON, because it has to be readable by a phone that does not have your keys. Treat an exported backup like a document: it contains your trips in the clear. It deliberately does not contain the credentials for any published link.

The three times Voylen talks to a server

1. Searching for a destination

What you type in the destination box is sent to OpenStreetMap's Nominatim service to turn it into a place. The request carries the text and a string identifying the app. It carries no account, no device id and nothing else of yours — but, like any request to any website, it reaches OpenStreetMap from your IP address. We neither see nor store that. Nominatim is operated by the OpenStreetMap Foundation under their privacy policy.

2. Fetching a forecast

The coordinates of the destination you picked are sent to Open-Meteo, along with which daily values to return (temperatures, rain chance, weather type, sunrise and sunset), how many days ahead to forecast, and a request for times in the destination's own time zone. The trip's dates are not sent: the app asks for the standard forecast window and picks out the trip's days on your phone. It is the destination, not you: Voylen never asks for location permission and cannot read your position. Before the request goes out the coordinate is deliberately rounded to two decimal places — about a kilometre — which is finer than any forecast model resolves anyway, so even if you searched for a precise address rather than a town, what leaves is the neighbourhood and not the doorstep. The result is cached on your phone.

3. Publishing a checklist

This is the only feature that sends your content anywhere, and the only one that stores it. It is off until you turn it on for a specific list, and a sheet shows you exactly what will be sent before anything is.

Your own category names are deliberately not sent: how you file things is your business and tells a reader nothing. If you publish the list again after changing it, Voylen shows you what changed and asks again. Consent is recorded against the exact contents you approved — it is not a switch you flip once.

Who can see a published list

Anyone who has the link. It contains a random 100-bit key; the page is not listed, not indexed, not searchable, and cannot be reached by guessing, so in practice that means the people you sent it to — but the link is the key, and whoever holds it can pass it on. Treat it accordingly, and turn it off if it travels somewhere you did not intend. Voylen stores only the SHA-256 hash of that key, so a copy of our database does not yield a working link.

Whoever holds the link can tick items off and nothing else. They cannot add, rename or delete anything, and they cannot see any other list. They are never asked for an account either.

How long a published list is kept

Every link has an expiry date, shown to you before you publish. The maximum is 60 days and it cannot be extended.

• You can turn a link off at any time. The moment that request reaches us the content is deleted, in that same request — not queued for a later clean-up. If you are offline when you ask, the app holds the instruction and keeps trying, and tells you it is still trying rather than claiming the link is already off.
• At expiry the page stops working straight away. That check runs on every request, so an expired link is unreadable the moment it lapses.
• The words behind an expired page are deleted by a scheduled clean-up that runs every hour, so normally within an hour or so of expiry. We say "normally" rather than promising a deadline for two honest reasons: a scheduled job can be delayed, and each run clears a fixed number of lists oldest-first, so an unusual backlog drains over several runs. Turning the link off yourself is the immediate route.
• What survives is a marker: the hashes of the link's two keys, a few opaque references to the updates it received, and the dates. It holds no trip name, no names and no items, and it exists so that a link you turned off can never be brought back.
• The marker is removed by a clean-up run once more than 30 days have passed since the date the link was originally due to expire — not 30 days after you turned it off, and, like the step above, on a run rather than to a deadline. That is deliberate, and it is the one place where privacy loses to safety: what the marker guards against is a publish that was already on its way when you revoked, and such a request stays capable of recreating the page right up until the original expiry date. Dropping the marker sooner would reopen exactly the hole it exists to close. The one exception is a link you turn off before its publish ever reached us: we never held that link, so the app sends its expiry date along with the request to turn it off. Its marker is kept until 30 days after the link's own expiry date, or 90 days after that request reaches us, whichever is later — never more than 430 days after the first such request, however far off a wrong phone clock puts that date — and is then removed by the next clean-up run.
• One thing is kept indefinitely: the SHA-256 hash of a link that was published and has since been turned off or has expired, on its own — no second key, no dates, nothing else. It exists so that nobody, including whoever else holds the old link, can ever publish something new under it. It contains nothing readable: it cannot be turned back into the link, and it holds no trip name, no names and no items. A link turned off before it was ever published was never served to anyone, so nothing about it is kept once its marker is removed.

One honest limit. Deleting a trip on your phone, or uninstalling Voylen, does not by itself take down a page you published — that needs a connection, and Voylen keeps the credential to do it. Uninstalling destroys that credential, and the page then stays up until it expires. Using “Delete my data” in Settings first sends each credential to api.voylen.app to turn the links off; if that fails (for example you are offline), the app tells you, and the credential is deleted anyway. The app says this where it matters; turn links off before you uninstall.

Abuse prevention

Because there are no accounts, requests to Voylen's API are limited per network. To count them without keeping a record of who you are, your IP address — for an IPv6 address, only its first half, which identifies the network rather than the device — is put through a keyed hash and only the result is stored, alongside an hour and a count. The address itself is never written down. A row only counts towards the hour it belongs to, and the hourly clean-up deletes every row more than three hours old — so a row lasts under five hours, or longer only if a clean-up run is missed.

Cloudflare operates the servers and the database, as our processor, and handles the ordinary request metadata any web service sees. Data is stored in Cloudflare's D1 database. Published list content is not end-to-end encrypted: it is stored so it can be served to a browser, which means Voylen could read it. We are telling you that rather than implying otherwise.

Children

Voylen is not directed at children and does not knowingly collect anything from them. A family profile you create for a child lives only on your phone and is never part of a published checklist.

Your choices

• Withdraw consent for a published list by turning it off, in the app under the trip or in Settings › Shared links. That is also the deletion request — it deletes the content directly.
• Delete everything local with Settings › Delete all data. Turn off published links first: this wipes the phone, not the server.
• Use Voylen with no network at all. Everything except the three things above works offline.

If you cannot reach a link you published — a lost or wiped phone — write to us with the link and we will take it down.

Your rights, and the legal basis

If you are in the UK, EU or a jurisdiction with comparable law:

• Publishing a checklist runs on your consent, given per list and withdrawable at any time by turning the link off.
• The hashed rate-limit record runs on legitimate interest — keeping a service with no accounts from being abused — and is minimised by design: a keyed hash instead of an address, kept about a day rather than months.
• Access and portability are built in rather than a request queue: Settings › Backup exports your trips and everything in them as a JSON file you keep. It leaves out one thing on purpose — the credentials for links you have published — because a backup is an unencrypted file people mail to themselves, and those credentials would let anyone holding it read and delete your published lists. There is no account, so there is no other store of your trips to ask us for — the only copy held anywhere else is a list you have published and not yet turned off, which is described above, which you can read at its own link, and which you delete yourself.
• Erasure is turning a link off (server) and Settings › Delete all data (device).
• We do not sell or share personal information as those terms are used in US state privacy law, and there is no advertising or cross-context behavioural tracking to opt out of.

Servers and storage are Cloudflare's. If you think we have handled something wrongly, write to us first — and you retain the right to complain to your data protection authority.

Contact

Revolt Bots · [email protected]
To report a shared list: [email protected]

If this policy changes in a way that affects what is sent, the app asks for your consent again rather than relying on the consent you gave to the previous version.