EFFECTIVE · 28 SEPTEMBER 2026

We don’t have accounts. We don’t have analytics. We don’t have crash reporters that phone home. Everything Quartermaster knows about your library lives on your device, and your credentials are sent only to the servers you configure. The optional features are push notifications (a small relay server we operate), instant alerts (a ntfy server you choose), iCloud sync (your own iCloud account), QM Companion (software you run on your own server, which can also send you alerts), and metadata lookups with your own TMDB or Hardcover key. None of them ever sends us your server addresses, API keys, media library, or anything that identifies you.

What stays on your device

Server addresses and API keys you enter are stored on your device only. API keys and passwords are kept in the operating system’s keychain (hardware-backed secure storage). They are sent only to the matching server you configured, as part of talking to it, never to us, never to anyone else.
Everything the app computes (dashboards, statistics, your taste profile) is calculated locally from your own servers’ data and stored on your device. None of it leaves your phone.
Books you open in QM Reader (Quartermaster 1.3 and later) are kept on your device so they open faster next time. Anything that syncs, such as your audiobook position, goes to your own book server, never to us.
Backups are created only when you ask, are encrypted with a passphrase only you know (scrypt key derivation + AES-256-GCM), and are saved wherever you choose. We never receive or store them. If you lose the passphrase, no one (including us) can open the backup.

Optional: push notifications (our relay)

Real push notifications need a server, because Apple only accepts pushes from the app developer. If you switch push notifications on, this is the one place Quartermaster uses a server we operate. It is designed to know as little as possible.

How it works. Your own services (Radarr, Jellyseerr, and so on) send their event webhooks to a relay address that contains a random install identifier. The relay turns each event into an Apple push notification for your device and then forgets it.
What the relay stores: the random install identifier, your device’s Apple push token, a hashed proof-of-ownership secret, your Now Watching preference, and (only while one is running) the technical tokens that drive a Live Activity. That is the full list.
What the relay never stores: your server addresses, API keys, name, email, IP-address logs of your services, or the content of any event. The notification text (for example a title your service just imported, the name on a request, or what is playing) passes through in memory, is mapped to a push, and is dropped. It is not written to any database.
Who else is involved. Delivery goes through Apple’s push service, so Apple carries the notification content in transit, exactly as it does for every app’s notifications. The relay runs on Cloudflare’s infrastructure, which, like any internet service, sees connection metadata (such as IP addresses) and keeps short-lived operational logs. There is no analytics of any kind.
Turning it off unregisters your device and deletes the stored token, secret hash, and preferences from the relay.
Practical note: the webhook address you paste into your services contains your random install identifier. Treat it like a private URL; it can only ever cause notifications to be sent to your own device, and it cannot read anything.

Optional: instant alerts (ntfy)

Instant alerts wire your services directly to a ntfy server. We are not in the path at all: events go straight from your service to the ntfy server you choose. If you use your own ntfy server, nothing involves any third party. If you use the default ntfy.sh, a public service run by a third party, your alert messages (event text such as titles) are delivered through it under a long random topic name. ntfy.sh topics are readable by anyone who knows the exact topic URL, so the app generates an unguessable one; for stronger privacy add an access token or self-host.

Optional: iCloud sync

If you enable sync, your configuration (profiles, server addresses, and the API keys needed to use them) is encrypted on your device with a passphrase only you know (the same scrypt + AES-256-GCM scheme as backups) and stored in your own iCloud account’s key-value storage. Apple hosts that storage under your Apple ID; we never receive or see it, and without your passphrase it is unreadable, to us, to Apple, and to anyone else.

Optional: QM Companion (your own server)

QM Companion is separate software you install and run on your own server. We don’t host it and never see it. It talks to the app in two ways, both directly between your device and your server.

Setting up from Companion. Companion prepares a one-time package of your service addresses and keys, encrypted and opened with a separate setup code. It expires after three minutes and works once. Your device collects it straight from your server; nothing passes through us.
The live link (Pro). If you pair your device with Companion, you approve it on your server by matching five words. The app keeps one credential in your device’s keychain and talks to your Companion over HTTPS, with no relay in between. You can revoke it from Companion’s Devices page at any time.
Companion itself has no telemetry and no account of ours. It checks GitHub for newer releases, which you can switch off with COMPANION_UPDATE_CHECK=false.

Optional: alerts from your Companion

In Quartermaster 1.3 and later, with Pro and a paired Companion, your own server can send alerts to your device. This route does not use our relay. It uses Expo’s push service (part of the tooling Quartermaster is built with) and Apple’s.

Turning them on. The app asks Expo’s push service for a push token for this device and gives that token to your own Companion over the live link. We never receive it.
Sending an alert. Your Companion sends the alert text and that token to Expo’s push service, which delivers it through Apple’s. Expo and Apple carry the alert text in transit, as Apple does for every app’s notifications.
What your Companion keeps. Your alert settings, registered devices and up to 500 past alerts, encrypted on your own server.
Turning them off. Switch them off in the app, or set ALERTS_ENABLED=false on your Companion to stop it accepting or sending alerts at all.

Optional: metadata with your own keys

Some screens can use details from outside your own servers, but only if you add your own key. Each key is kept in your device’s keychain and sent only to the service it belongs to. Neither route passes through us.

TMDB. Cast and crew, the Browse catalogue and the New to You picks need a metadata source, and from Quartermaster 1.3 so can the Home’s trending and browsing rows. If you paste your own TMDB Read Access Token into Settings, then Metadata, the app calls TMDB’s API directly, and those calls carry what TMDB needs to answer them: the title you are looking at, the words you type into a catalogue search, the actor and director names from the taste profile the app worked out on your device, and, for Because you’re watching, a title you are watching. Your token ties the calls to your own TMDB account, so they are covered by TMDB’s privacy policy. Nothing about your servers is sent. With no token saved, the app never contacts TMDB’s API at all.
Hardcover. In Quartermaster 1.3 and later, QM Reader’s Discover uses your own Hardcover key to fetch book lists, charts, genres and book details. Nothing from your library is sent. Hardcover receives the requests with your key, so they are tied to your Hardcover account.

Family invites

A Family invite is encrypted with a passphrase you set, using the same scheme as backups, and carries only what the other device needs to browse and request. You can share it as a QR code, a file or a link. In the link, the invite sits after the #, and browsers never send that part to a website, so our site never receives it. Our website analytics are set to drop it too.

Wi-Fi network name

You can optionally tell Quartermaster your home Wi-Fi name so it uses a local address at home and a remote one elsewhere. iOS only reveals the Wi-Fi name to apps with location permission, so the app asks for When-In-Use location for exactly this purpose. Your location is never read as coordinates, never stored beyond your own settings, and never sent anywhere.

Where the app connects

Your own servers. The app’s network traffic goes to the server addresses you configure, on your network or VPN. What those servers log is governed by your own setup.
Artwork. Poster and artwork images may load from the image services your servers reference (for example TMDB’s public image servers, which Jellyseerr uses for search results). These are plain image downloads; like any web request, the image host sees your device’s IP address. No identifiers, accounts or app data are attached.
App Store purchases. Pro, whether the one-time unlock or a monthly or yearly subscription, is processed by Apple. To validate the purchase, the app uses RevenueCat, which receives the Apple purchase receipt and a randomly generated, anonymous identifier, never your name, email, or anything that identifies you to us. It is used solely so your purchase restores reliably.
App fixes. On launch the app asks Expo’s update service (part of the tooling Quartermaster is built with) whether a newer copy of its own code is available, so fixes can reach you without waiting for a full App Store release. The request carries the app’s version, platform, and a randomly generated, anonymous installation identifier used to count update deliveries, never your name, your servers, or anything you configured. See Expo’s privacy policy.

What we never do

No advertising, no trackers, no fingerprinting.
No selling, sharing, or monetising data: there is no data to sell.
No reading your media library: your library data goes from your server to your screen and nowhere else. The exceptions are the notification text you have chosen to have pushed (through our relay, which doesn’t store it, or through your Companion and Expo), and what is sent to TMDB when you have saved a TMDB token: the titles you look up, your catalogue searches and the names from your taste profile, as described above.

The site, too

The same stance applies to this website, with one thing we’re upfront about: we use privacy-friendly, cookieless site analytics to see how people use the site and how quickly pages load. None of it sets cookies, follows you across other sites, or collects personal data, and nothing is ever sold or shared. The typeface you’re reading is self-hosted on our own domain, so loading it makes no request to Google or any third party. We set no tracking cookies, and we don’t share any server-side request data with third parties.

Children

Quartermaster does not knowingly collect data from anyone, including children.

Changes

If a future version ever changes any of the above, this policy and the App Store privacy label will be updated before that version ships, and the change will be called out in the release notes. This revision exists for exactly that reason: it added QM Companion, alerts from your Companion, metadata lookups with your own keys, Family invites and QM Reader, including the parts that arrived with Quartermaster 1.3, before 1.3 reached the App Store.

Contact

Quartermaster is developed in the United Kingdom. Questions: [email protected].