Privacy

This covers the hosted service at starbridge.run and the Starbridge Android app. A server you host yourself keeps its data on your own machine. Last updated: 13 October 2026.

Operator: Tom Vaucourt, an individual in France, running Starbridge as a non-professional. Contact: privacy@starbridge.run. Host: Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Germany, +49 9831 505-0.

What the server stores

• Your GitHub account's numeric id, which identifies you at sign-in. The server does not store your login, name or email. Sign-in asks GitHub for no permissions; the server uses GitHub's token once to read the id, then drops it.
• The public keys of your devices and machines, and the names you give them, in a list they sign.
• Hashes of your sign-in sessions, which expire after a year, and of machine tokens. A new machine's token is also kept as is with its pairing request for about 10 minutes, so a reply lost on the way can be sent again; a backup taken in that time keeps it too.
• For each device that gets notifications: the push service, its token or endpoint URL, and the keys that encrypt pushes to it.
• How long notifications wait while you are at a screen, if you change it.
• Your decisions, answers, quota snapshots, permission prompts and their answers, runs, and the notices that close an item, say an agent is waiting or snooze a decision. Your devices and machines encrypt them before upload, and the server cannot read them. It does see the kind of each one, its id, who sent it, which devices it went to, which item it answers or closes, its size, when it arrived, was updated or was answered, until when a decision is snoozed, whether an item asked for a notification, and until when its notification waits while you are at a screen.

The server deletes them on this schedule:

• answered decisions and their answers, 7 days after the answer;
• permission prompts, their answers and settled notices, 7 days after they arrive;
• runs, 1 day after their last update;
• unanswered decisions and quota snapshots, 30 days after they arrive, or unanswered decisions 7 days after they arrive once an account holds more than 1000; a machine's new quota snapshot replaces its last one;
• a request to pair a new device or machine, 10 minutes after it is made.

Your account, device list and push targets stay until you delete them (see Deletion). A nightly copy of the database is kept on the server for 7 days, and Hetzner keeps its own backups of the server, with those copies, for 7 more. Each nightly copy is also encrypted and kept on a server at Oracle for 14 days. Deleted data can remain in backups for up to 2 weeks.

Whether you are at a screen

While a Starbridge page or the app is in front and in use, or a machine where you turned this on has had keyboard or mouse input in the last minute, it tells the server so every 30 seconds: yes or no, never what you did. The server uses it to hold notifications for a few seconds while you are at a screen. It keeps the last answer from each device or machine in memory for 75 seconds, never writes it to disk, and a restart clears it.

Logs

The web server (Caddy) keeps no access log. The server, Caddy and the web page log startup, errors and failed pushes; these lines can include an account id or a push endpoint, but not IP addresses or your content. Caddy's error log is the exception: for a request that failed at the proxy, it can hold the request's IP address, path and headers. Each keeps five files of 10 MB, so how long a log covers depends on traffic. To enforce rate limits, the server counts requests per IP address in memory; it never writes them to disk, and a restart clears them. Addresses blocked for abuse are kept in a block list until unblocked.

Usage counts

To learn how Starbridge is used, the server counts what it already handles, per day. During the day it keeps one row per event; the rows that count active accounts, devices and machines hold their ids, so each counts once. When the day ends, the server keeps only the day's totals and deletes those rows. The totals hold no ids, and only the operator can read them, on the server. The daily totals are:

• accounts, devices and machines that used the server that day, with devices split into the web page and the Android app;
• accounts, devices and machines in total, and new accounts;
• items posted, by kind: decisions, answers, permission prompts, their answers, notices that a prompt or decision is over, quota snapshots, run updates and waiting states;
• answers by client (web page or Android app), and how long decisions and permission prompts waited for their answer, as the median and the 90th percentile;
• pushes by push service and outcome (sent, failed, gone, no route, dropped), and the same for pushes relayed for self-hosted servers;
• push targets by push service;
• which releases of the Android app, the web page and the CLI were in use.

Who else sees what

• GitHub, when you sign in: that your GitHub account uses Starbridge.
• Google Firebase Cloud Messaging, for the Android app: your phone's push token and each push, which holds the item's kind and ids and either its encrypted content or nothing more. Google cannot read the encrypted content.
• Your browser's push service (Google for Chrome, Mozilla for Firefox, Apple for Safari), when you turn on notifications on the web: the endpoint and pushes encrypted for your browser alone. It sees their size and timing.
• Your UnifiedPush distributor, if you use one instead of Firebase, sees the same as Firebase would.
• Hetzner hosts the server in Helsinki, Finland, and stores its backups.
• Oracle stores an encrypted copy of the nightly backup in Frankfurt, Germany. The key that decrypts it is not on Oracle's server or ours.

Self-hosted servers without their own push credentials send pushes through starbridge.run, which passes them to these services. Those pushes carry only encrypted content or ids. There are no ads, and no analytics beyond the usage counts above and the page analytics below.

Page analytics

The landing page, the docs, this page and the terms count visits with Umami, which runs on the same server; the Android app does not. For each view Umami records the page, its title, the referring site, your browser, operating system, device type, screen size and language, and the country, region and city it looks up from your IP address. On the landing page, clicking a sign-in button, a docs link or a way to get the app, or copying an install command, records which one. The signed-in app counts no views. It records which error screen it showed, if any, and when it is installed as an app. For an account made in the last two days, the server also records, once each, these steps: the first sign-in and the app it came from, the recovery key saved, the first machine paired, a second device added and the first answer sent, with the app that sent it. It sends them with a hash of the account id, so Umami can tell one account's steps apart from another's; nothing else about the account, its machines or its content goes with them. A request that sends Do Not Track records no step. Since the server knows when each account was created, the operator could match that first sign-in to your account. Umami sets no cookie, stores nothing in your browser and does not store your IP address: it tells visitors apart by a hash of the IP address, the browser and a salt that changes every day, so a visit to the public pages cannot be traced back to you or linked to your visits on other days. A browser that sends Do Not Track is not counted. Umami keeps its records for 180 days at most, and the nightly backups keep them for up to 2 weeks more.

Deletion

Removing a device or machine from your account ends its sign-in and deletes its push targets; a push target the push service reports as gone is deleted too. Its name and keys stay in your account's signed device list, which nothing rewrites, and the items encrypted for it stay until the schedule above deletes them. To delete your whole account, use Delete account in Settings, on the web page or in the app: the server deletes the account, its device list, devices, machines, items and push targets at once, and signs out every device and machine. Backups age out within 2 weeks after.

Your rights

The GDPR applies. The legal basis for storing your data is running the service you signed up for; logs and rate limits rest on the operator's legitimate interest in keeping it working and safe. You can ask to access, correct, delete or export your data, or object to its processing, at privacy@starbridge.run. Your content is encrypted, so only your devices can export it. You can complain to the CNIL (cnil.fr) or your own country's data protection authority.

Changes

Changes to this page are posted here with a new date.