Effective 28 August 2026

Four separate things are worth keeping apart: this website, the server you run yourself, the Playarr apps, and the hosted Playarr service.

Who this policy covers

This policy applies to the Playarr Android application with package nameapp.playarr.mobile, the Playarr web application atplayarr.app, and the short-lived device-linking service on that domain. Playarr connects to a Playarr Server chosen and operated by you or your server administrator.

This website

This site is a set of static pages. It sets no tracking cookies, runs no analytics, embeds no third-party scripts, and has no forms to submit. The single piece of state it keeps is your light or dark theme preference, stored in your own browser and never transmitted anywhere.

Whoever hosts these pages will keep ordinary web-server request logs, as any web server does.

The server you run

A Playarr server is yours. Your library, your accounts, your watch history and your artwork cache live on your own storage, under your own control. The project operates no service that this data is sent to.

The server does reach out to the library-management applications and metadata sources you configure it to reach, that is the point of configuring them, and it fetches artwork from the URLs those applications provide, caching it locally.

When a user with request rights asks for a title that is not in the library, the server sends it where the administrator's "Where requests go" setting in Playarr Admin says. The default is Direct, to your own library manager (Radarr or Sonarr). An Ombi or Seerr style request manager receives requests only when an administrator chooses it there (a chosen one that is not enabled makes the request fail, with no fallback), and "Direct + mirror" does both. Playarr itself obtains no media; what those applications then do is set up and controlled by the operator, not by the Playarr project. What is sent:

• to a request manager: the requested title, its metadata identifiers (TMDB, TVDB), any seasons, and the request manager account the requesting user is mapped to;
• to Radarr or Sonarr directly: the title record that application's own lookup returned for it (title, year, identifiers, artwork links and overview), the default root folder and quality profile an administrator set on that instance (a direct request is refused if either is unset), and instructions to monitor it and search for it immediately.

The search terms users type into search are sent to your Radarr or Sonarr lookup so that titles outside the library can be shown.

Two other requests leave your server. On first use it downloads the all-MiniLM-L6-v2 embedding model (used for similar-title suggestions) from Hugging Face and caches it locally, and it fetches artwork from the addresses your library managers provide, which are usually on image.tmdb.org.

Sign-in details go directly to your selected Playarr Server. The server may hold account and profile details, library metadata, artwork, watch history, playlists, download and playback state, server addresses, device identifiers, sessions, invitations and push notification registrations. The person or organisation operating that server controls this data, its backups, retention and deletion. Playarr's hosted service does not receive your password, library, watch history or media files.

Ask your server administrator to correct or delete server-side account data. Server administrators can also revoke sessions and remove push registrations.

The Playarr apps

This covers the Playarr apps for iPhone, iPad, Apple TV, Android, Android TV and the web. The developer collects no data from them. The apps contain no advertising, no tracking, and no analytics or crash-reporting libraries, and they do not follow you across other companies' apps or websites. They do include Google components that talk to Google services, described under "Notifications and Google services" below, and which you can avoid.

What the apps keep on your own device:

• the addresses of the servers you add,
• your sign-in session, held in the operating system's secure storage (the Keychain on Apple devices),
• your preferences, such as language, theme and playback settings,
• anything you choose to download for offline viewing, with its playback progress, which is removed when you delete the download or the app,
• a random per-install device identifier, and authentication and refresh tokens.

Everything else the apps show, including your library, watch history and accounts, is fetched from your own server and handled as described under "The server you run". Signing out, or deleting the app, removes the session and settings from the device. Deleting your account or history is a matter for whoever runs your server.

On Apple devices the app asks for local network access so that it can find your server and any Chromecast devices on your home network. Chromecast support uses Google's Cast software, which is governed by Google's own privacy policy. Apple may separately give the developer aggregate, non-identifying crash and usage reports if you have chosen to share them in your device settings. Beta testers on TestFlight are also subject to Apple's TestFlight terms.

Notifications and Google services

Firebase Cloud Messaging (Android and Android TV). In production builds configured for invite notifications, Google Firebase Cloud Messaging creates an app-installation identifier and a push token after you sign in. Google receives that token and the metadata needed to deliver a message to your device, such as the app package name and timing, and it carries the notification itself. The token is also registered with your selected Playarr Server so it can deliver invitation notifications. Playarr does not use Firebase Analytics, advertising SDKs or cross-app tracking. To stop this, turn off the "Invite approvals" notification channel in Android's notification settings (the app has no separate in-app switch), which stops them being shown, or use a device or build without Google Play services, where no push token is created. Removing the push registration is a matter for your server administrator. Google's handling of Firebase data is governed by its own terms and privacy policy.

Google Cast sender (Android). The Android app includes Google's Cast sender framework, supplied through Google Play services. It looks for Cast devices on your local network and, when you choose to cast, exchanges the session and playback control messages with the Cast device through Google's Cast framework. Details of the item you are casting are sent to the Cast device so that it can play it from your server. To avoid this, do not cast. Google's handling of Cast data is governed by its own terms and privacy policy.

Play In-App Updates (Android). The Android app includes Google's Play In-App Updates library, which contacts Google Play to ask whether a newer version is available and to run the update. Google receives the ordinary information such a request involves, such as the app package name and installed version. It applies to installs from Google Play; Google's handling of that data is governed by its own terms and privacy policy.

The hosted web app

playarr.app does not use advertising cookies, analytics pixels or behavioural profiling. If your server is configured for browser notifications and you allow them, the web app uses Firebase Cloud Messaging in the same way as described above. When the Player page opens in a browser that can cast, the web app loads Google's Cast sender script from www.gstatic.com, even if you never cast, so Google's servers see that request (your IP address and user agent). Avoid it by using a browser without Cast support, or by blocking that address. Casting itself then works as described for Android above. The signed-in web app can store server addresses, device identifiers, names, access and refresh tokens, interface preferences, download records and media, and playback progress waiting to sync in your browser. Hosting and network providers may process ordinary request information such as an IP address, timestamp, requested path and user agent for delivery, reliability and abuse prevention. Playarr does not sell personal data.

When you sign in to the hosted web client, playarr.app sets a playarr_signed_incookie holding only 1. It is used only to decide whether the home page shows the app or this site. It is strictly necessary, is not used for tracking, and is removed when you sign out.

The hosted Playarr service

playarr.app hosts the Playarr web application and can broker the first handshake between a new app and a server it has not met. That is the one moment something passes through infrastructure the project operates.

The short-lived link record contains only:

• the device secret generated by the app,
• the server addresses you approve,
• the client platform, and
• a single-use device code.

It never contains a password, library data, a bearer token, or a refresh token. The record expires after five minutes, with only a brief redemption grace period, and is then deleted. After linking, the app talks to your server directly and nothing further routes through the hosted service.

Security, retention and deletion

The hosted playarr.app service and the Google Play Android app require HTTPS. Sideloaded builds can also connect to an HTTP address chosen by you or your administrator, so only use an unencrypted address on a network you trust. Local records remain until removed in the app, cleared by the operating system or removed by uninstalling. Server-side records and backups follow the server operator's retention policy. Device-link records expire automatically as described above.

To request deletion of an account and associated server-side data, follow theaccount-deletion instructions. Signing out does not itself delete a server account or all local records.

Your choices

You can avoid the hosted linking service by entering a server address and signing in directly. You can disable notifications, remove downloads, sign out, clear app storage or uninstall the app at any time.

Changes

If any of the above changes, particularly if analytics are ever added to this site, or the hosted service ever holds more than it does today, this page will be updated to say so before the change ships. The effective date above identifies the current version.

Contact

Questions about this policy, or requests about data held by the hosted service, can go tosupport@playarr.app. Playarr is developed by Thomas McFarlane. You can also use the contact method on thePlayarr repository. Do not put passwords, tokens or private information in a public issue.

Rights holders and others reporting abuse can use the same address. Please include the work concerned, where it appears, your contact details, and a statement that you believe in good faith that the use is not authorised. Playarr hosts no content, so complaints about media on a self-hosted server go to the operator of that server.