Skip to content
Coming soon

Privacy Policy

This policy covers the three services Sovereign Media LLC runs for Sovereign, the licensing service, the metadata service and the download service, and this documentation site. It also describes what the self-hosted Sovereign software stores and sends, which we don’t receive.

Last updated: 31 October 2026


Sovereign is self-hosted. Your media, your accounts and everything anyone watches stay on the server you or your administrator runs, and none of it reaches us. The client apps for web, Roku, Android, Google TV and Fire TV talk to that server and nowhere else, apart from loading artwork from The Movie Database.

We run two services that every server can talk to:

  • The licensing service, at account.sovereign.watch, issues free trials and sells licenses. It knows a server by its install ID. If you buy a license, it also keeps a reference to you as a Stripe customer and a history of the servers each license has been on. Your email address and name stay with Stripe, and the service asks Stripe for them when it needs them. It keeps a customer’s records until two years after their last license ends, and the country each request came from for 90 days.
  • The metadata service looks up films and shows on The Movie Database for every server. It keeps the answers in a shared cache, counts how many servers use it each day, and keeps nothing that names a server for more than a day or two.

And one you download Sovereign from:

  • The download service hands out the Sovereign server image when you or your tools download it with Docker, Podman or Kubernetes. It counts downloads by version, place and kind of tool, doesn’t store your address, and keeps nothing that could tell one downloader from another for more than a day or two.

We show no advertising, sell no data and don’t track you. You can ask us at any time for a copy of what we hold about you, or for it to be erased.


Sovereign Media LLC runs the licensing service, the metadata service, the download service and this site, and is the controller for the personal data they handle.

For anything about your data, write to privacy@sovereign.watch.


The licensing service is where a server starts a free trial, buys a license, renews it and moves it to another server. Everything starts from the server’s own License page, and there’s no account to create. A server that never asks for a license never contacts it. The licensing pages describe what it does.

Data Why we use it Legal basis How long we keep it Who else sees it
Your server’s install ID To issue a trial or license for that server, and keep each license’s history Contract; legitimate interests, for a trial Until two years after your last license ends Your server, in its license
Your email address and name, read from Stripe when needed To email you codes that move a license, and to find your licenses when you ask for help Contract Not kept: read from Stripe each time Stripe, which holds them; Cloudflare, which sends the email
References to your Stripe customer and subscription To keep your licenses in step with your subscription Contract As above Stripe
Your licenses: plan, what it includes, term It’s what you bought Contract Until two years after the license ends Your server
Each license’s history: the servers it has been on, their Sovereign version, and when Support, and the limit on how often a license can move Contract; legitimate interests With the license No one
The country each request came from, on that history and on the events below Support, and spotting misuse Legitimate interests 90 days No one
Events on a license: a move it refused, and any change our staff made to it, with who and why Support, and a record of what we changed Legitimate interests With the license No one
A random value each server run generates, with when it was first and last seen Spotting two copies of one server Legitimate interests 30 days after it was last seen No one
The last day a server was counted, and which of our signing keys its license carries Counting servers once a day Legitimate interests 90 days No one
A purchase in progress: the server’s install ID, version and country Completing the purchase Contract About a day after you pay, or an hour after an unpaid checkout closes Stripe, which receives only the price
A request to move a license by email: the codes, the asking server’s install ID, version and country, and which customer each email went to Sending the codes, at most three an hour to any one customer Legitimate interests Up to an hour and a quarter Stripe, which is asked whose the address is; Cloudflare, which sends the email
A record of each recovery email we tried to send, naming the customer the address belonged to, if anyone Answering “I never got the email” Legitimate interests 90 days No one

Trials. When a trial’s records are deleted, the service keeps only a form of its install ID that can’t be turned back into it, so that server can’t start a second trial.

Refunds. When a server refunds its license from its License page, the service keeps the same kind of one-way form of its install ID, for good, so that server can’t be refunded that way a second time. It names nothing. The refund itself is recorded by Stripe.

Recovery emails. The address you type isn’t kept, in any form. The service asks Stripe which customers hold it, and sends the codes to it if anyone does. The codes work for 15 minutes. Each record of an attempt holds whether the email went, which customer the address belonged to (or that it belonged to no one), the asking server’s install ID, and how many licenses it covered. An attempt for an address no customer holds names no one, so it can’t be found again by that address.

Where the data comes from. Your email address and name come from Stripe, which collects them at checkout and keeps them. The country is worked out from the address a request comes from. Everything else comes from your server or is created by the service.

Buying a license needs an email address, which you give Stripe at checkout. Without one, a license can’t be moved to a new server by email.

Check-ins. A server with a license checks in about every 12 hours, and each time it starts, to confirm it still holds its license and to collect a renewed one. The check-in carries the license, the random value described above, and the server’s version number. Nothing about the server’s users, or anything anyone has watched, is sent. A server with no license never checks in.

Location and counting. From the address a request comes from, the service works out the country, the region (a state or province, never anything finer) and whether the address belongs to a hosting provider. It doesn’t store the address, look up the city or anything more precise, or record the network’s name. The country is kept as the table says. The region and the hosting flag go only into daily totals of how many servers there are, by region, plan and version, which name no server and in which no figure describes fewer than three servers.

Decisions made automatically. The service decides some things on its own: whether a server can start a trial, and whether two copies of one server seem to be sharing a license. Either result shows a notice on the server. Neither stops the server or anything it plays, so neither is a decision with legal or similarly significant effects on you.

Logs. The service doesn’t keep a log of the requests it receives. Its own diagnostic messages can name a license or a purchase, never an email address, a name or a request’s address, and Cloudflare keeps them for up to 7 days.


Every Sovereign server looks up films and shows on The Movie Database through Sovereign’s metadata service, so no server needs an API key of its own. A server uses it when its library changes: to identify a new file, fetch a title’s details and artwork addresses, and fill in cast and crew.

Data Why we use it Legal basis How long we keep it Who else sees it
The address the request comes from To limit requests per address, and to work out the country, region and hosting provider for the daily totals Legitimate interests Not stored No one
What’s looked up: an ID, or a title and year read from a file or folder name To answer it from a cache shared by every server Legitimate interests Up to about two weeks, without which server asked The Movie Database, without anything about your server
An anonymous token your server makes afresh each day, and the license standing it reports To count each server once a day Legitimate interests The token isn’t kept; the day’s count is deleted after a day or two No one
The kind of lookup, whether the cache answered, the result, and the version of Sovereign that asked Running the service Legitimate interests Up to 7 days in logs; counts for about three months No one

Your server makes the token from the date and a secret key that never leaves it. Nothing about your server goes into it, so neither service, and nobody at Sovereign, can tell which server sent it, and because it changes every day, one day’s token can’t be matched to another’s. The token is used only to count servers.

Versions before 0.0.10 send a token derived from the install ID instead. The licensing service holds install IDs, so for a server on one of those versions we could work out whether it was counted on a given day. Updating your server stops that.

To send neither the token nor the license standing, set Sovereign__DataSources__Tmdb__SendCensus to false (see the configuration reference). Your server then isn’t counted, and its lookups work exactly as before.

The daily totals count servers by country, region, hosting provider and license standing. They name no server, and no figure describes fewer than three servers.


The download service hands out the Sovereign server image to Docker, Podman, Kubernetes and the tools that keep a container up to date. It only ever sends the image: nothing is uploaded to it, and your server never contacts it once it’s running.

Data Why we use it Legal basis How long we keep it Who else sees it
The address the request comes from To limit requests per address, to work out the country, region and hosting provider for the daily totals, and to count how many different downloaders there were each day Legitimate interests Not stored No one
A daily key made from that address and a secret that changes every day To count each downloader once a day, and to tell which tag a download asked for Legitimate interests Deleted after a day or two No one
Which version was downloaded, the tag asked for (such as latest or a version number), whether the download finished, and how much was sent Running the service, and counting downloads by version Legitimate interests Up to about three months for each request; daily totals, by country only after 90 days No one
The kind of tool that asked (Docker, Podman, Kubernetes, an update checker and so on) and the operating system and processor type it reports Knowing which tools to support Legitimate interests The tool’s own description isn’t stored, only the kind it falls into, in the daily totals No one

Counting downloads. Most tools download an image in two steps: they ask which version a tag such as latest points at, then fetch that version. To count which tag a download asked for, the service remembers the tag under the daily key for two minutes and then forgets it. A tool that only asks whether a newer version exists, without downloading it, is counted as an update check.

The daily key can’t be turned back into your address, and because the secret behind it changes every day, one day’s key can’t be matched to another’s. It’s used only to count downloaders and to link those two steps.

Location. As with the other services, the country, region (a state or province, never anything finer) and whether the address belongs to a hosting provider are worked out from the address and go only into the daily totals. The address itself isn’t stored, and the city and network name aren’t looked up.

The daily totals count downloads by version, tag, kind of tool, processor type, country, region and hosting provider. They name no one, and no place is shown with fewer than three downloads. A download through a mirror or a company proxy is counted where the mirror is.

Logs. The service doesn’t keep a log of the requests it receives. Its own diagnostic messages never include an address, and Cloudflare keeps them for up to 7 days.


This site sets no cookies and loads nothing from Google. If you choose a light or dark theme, your browser remembers the choice in its own storage. Search runs in your browser against an index downloaded with the pages, so what you search for isn’t sent anywhere.

Cloudflare hosts the site and handles every request to it. We count visits with Cloudflare Web Analytics, which adds a small script from Cloudflare to each page. It records the address of the page you read (leaving out anything after a ?), the page that linked you here, your browser, operating system and kind of device, the country you’re in, and how quickly the page loaded. It sets no cookies, stores nothing in your browser and doesn’t fingerprint you, so it can’t connect one visit of yours to the next or follow you to other sites. We see totals and averages for the past six months, never a record of one visitor. We do this on the basis of our legitimate interest in knowing which pages get read and whether they load quickly.

The Pricing page asks the licensing service for the current prices, from your browser. That request isn’t logged.


  • Cloudflare hosts the three services and this site, counts this site’s visits, stores the services’ data and the server images the download service hands out, and sends the licensing service’s emails. It keeps the recipient and subject of each email for 31 days, and the services’ diagnostic messages for up to 7 days.
  • Stripe takes payments on its own checkout and billing pages, so we never see your card. It holds your card details, billing address, name, email address, any phone number you give it, your subscription and your invoices. Stripe processes payments for us, and is responsible on its own account for what it must keep for fraud prevention, tax and its regulators.
  • The Movie Database answers lookups the metadata service’s cache can’t, without anything about the server that asked. Your devices also load artwork from it directly, as described under The Self-Hosted Software.

Within Sovereign Media LLC, only the people who run the licensing service can see what it holds about you, to help when you ask. Only the people who run the services see the metadata and download services’ daily totals.


Cloudflare and Stripe are based in the United States and may process data there. Both are certified under the EU-US Data Privacy Framework and its UK extension, and both include the European Commission’s standard contractual clauses in their data processing terms as a further safeguard. You can read Cloudflare’s and Stripe’s terms on their sites.


You can ask us for a copy of the personal data we hold about you, in a form you can take elsewhere, and to correct it, erase it, or restrict how we use it. Write to privacy@sovereign.watch. We’ll answer within a month.

  • If you bought a license, write from the email address you paid with, or tell us what it is, and we’ll reply to that address.
  • If you only ever used a trial, we have no email address for you. Tell us your server’s install ID, which only someone with access to the server can read.

For a single license, you don’t need to write: Export Your Data on the License page of the server that holds it downloads everything we keep about that license. What We Hold About a License says what it includes and leaves out.

While a license is still active we need its records to keep it working. We’ll erase them once it has been cancelled, and if you cancel because you want your data erased, say so and we’ll do both. What Stripe holds about your payments, your email address and name included, is covered by Stripe’s own privacy policy, and Manage Billing on your server’s License page is where you change your billing details yourself. A new email address there is the one a license recovery uses from then on.


Where we rely on legitimate interests (keeping trials to one per server, spotting two copies of one server, counting servers, keeping a short history of where requests came from and of the emails we sent, the metadata service’s counting token, and the download service’s counting), you can object at any time, on grounds relating to your situation. Write to privacy@sovereign.watch, and we’ll stop unless we have compelling legitimate grounds that override your interests, or need the data to establish or defend a legal claim.


You can complain to the data protection authority where you live or work, or where you think the problem arose. In the United Kingdom that’s the Information Commissioner’s Office. We’d like the chance to put it right first, so please write to us too.


Sovereign Media LLC publishes the Sovereign server and its client apps, but doesn’t run your server and receives nothing from it apart from what the licensing and metadata services above describe. The person or organisation running a server is responsible for the personal data it holds. If you run your own, that’s you. If someone invited you onto theirs, it’s them, and questions about your data on that server go to them.

The rest of this section describes what the software stores and sends, so that you, or whoever runs your server, can rely on it.

What the server stores.

  • Accounts - username, email address, display name, a hash of the password, roles, preferences, the content rating limit, and the last sign-in. Kept until the account is deleted.
  • Social sign-in - if your administrator turns on Sign in with Google or Microsoft, the provider returns your email address, name and a link to your profile picture. The email address becomes your username, and the server downloads the picture once, when the account is created. Google and Microsoft learn that you signed in, under their own privacy policies; we don’t.
  • New accounts - when someone asks for an account, the server emails its administrators the person’s name and email address, through the mail server the administrator configures, and keeps a record of the email for 90 days.
  • Activity - sign-ins, what was played and when, with the IP address and user agent of each request. Kept for 90 days.
  • Playback progress and favourites - kept until the account, or the title, is deleted.
  • Devices - each device’s identifier, the name set on the device (which is often a person’s name), its make and model, its user agent and last IP address, and what it can play. Kept for 90 days after the device was last seen.
  • Error reports - the error message and stack trace, where in the app it happened, the app version and platform, and the account, device, IP address and user agent the server attaches. When a report arrives, the server removes email addresses, sign-in tokens and the query strings of web addresses from its text, before storing it or writing it to the log. The account stays attached, so your administrator can follow up. Kept for 30 days, and also written to the server’s log files.
  • Log files - the server’s own log, including usernames, which accounts started and stopped playing what, and error reports. Kept for 31 days, and administrators can download them.

Deleting an account removes it together with its playback progress, favourites, activity, error reports, profile picture and signed-in sessions, and every device only that account used. A device another account also uses stays, without its link to the deleted one. Two records outlive the deletion and age out as above: the log files, and the record of any email that contained the person’s address. The administrator is shown both before confirming the deletion. On a server with a purchased license, administrators can make a backup of every account on the server, which includes each account’s email address and password hash; it isn’t a per-person export.

What the apps send.

The apps send everything to the server whose address you enter, and nowhere else, apart from artwork (below):

  • Sign-in details - your username and password, or the result of a social sign-in, exchanged for access and refresh tokens.
  • Device information - a random identifier the app creates for itself, the name set on the device, the app version, the platform, model, screen and HDR support, connection type and measured speed, and the video formats the device can play.
  • Playback - what you’re watching and how far into it you are.
  • Favourites and preferences - titles you mark, your audio and subtitle languages, and your quality settings.
  • Error reports - when something goes wrong, the error and where it happened. Web addresses in a report have their query strings removed first.

Artwork. Until your server has cached an image, the app loads it straight from The Movie Database’s image servers, which see your device’s IP address. The web app also tells them the address of your server, as a browser does with any image. The Android apps currently also send their device identifier and any custom headers you’ve set with those requests.

Administrators’ browsers. On the web app’s admin pages, your browser checks Radarr and Sonarr directly, and opens Stripe’s checkout and billing pages.

What the server sends out.

  • To the licensing service, if it has a trial or a license: its install ID, version, license and the random value described above.
  • To the metadata service, always: its lookups, its version, the counting token and its license standing.
  • To The Movie Database, TheTVDB and the image hosts your Radarr or Sonarr report, to download artwork.
  • To Radarr and Sonarr, with your administrator’s API keys, and to Google or Microsoft, for social sign-in.
  • To your administrator’s mail server, for the emails above.

It sends no telemetry, analytics or crash reports anywhere.

What’s stored on your device.

  • Web - the device identifier, and your sign-in session in the browser’s storage, which includes your name, email address and role from the sign-in.
  • Roku - the server address, a refresh token, the device identifier and any custom headers you entered, in the channel’s storage.
  • Android, Google TV and Fire TV - the server address, the device identifier, any custom headers, and a refresh token encrypted with a key held in the Android Keystore, plus a cache of artwork. Android’s own backup and device transfer can copy the app’s settings, including the server address, device identifier and custom headers, to your Google account and restore them on a new device.

Signing out deletes the stored tokens.

The phone app shows what’s playing in its notification and on the lock screen, which can also reach Bluetooth devices, Android Auto and watches. The Android apps ask for internet access, to check whether the device is connected, and to keep the device awake while a video plays. The phone app also asks to keep playing with the screen off and to show a notification while it does, asking for the notification permission on Android 13 and later. None of the apps asks for contacts, location, storage, camera or microphone access, and none contains an advertising, analytics or crash-reporting library.


Neither the services nor the apps are directed at children. Accounts on a server are created by its administrator, who decides who gets one, and administrators can set a content rating limit for each account.


If this policy changes, the new version will be published here with a new date, and material changes will be noted in the release notes.


For anything about your data held by the licensing, metadata or download services, or about this policy, write to privacy@sovereign.watch. For your data on a media server, ask whoever runs it.

© 2026 Sovereign Media LLCdocs/v1.0.5@98b57ac305fc

Titles, artwork, people and descriptions shown in screenshots are fictional and were created for illustration. Sovereign doesn't include or supply any media: it plays the library you bring.