1. Who this policy covers
This policy applies to Flagship (operated by the Flagship team, sole proprietorship pending entity formation; the "Service") and to the websites flagshipserver.com and flagship.services, the iOS, Android, and webapp clients.
It does not cover services you install on your own Flagship server. Those services run on hardware you own, under your control, and their privacy practices are theirs. We provide a sandbox; we don't supervise its inhabitants.
It does not cover services you connect through the BYOK / browser features (Anthropic, OpenAI, Amazon, your bank, etc.). When you log into a third-party service from your Flagship browser, that service's privacy policy governs.
2. What we collect, and why
2.1 Account data (necessary)
When you create a Flagship identity, we store a username (your choice, lowercase letters and digits, up to 32 characters), the public key your phone derived for you, and a timestamp. The username is used to route public traffic; the public key verifies that signed actions come from your phone. We never receive or store the private key.
2.2 Sealed unlock blob (necessary)
To let you unlock your server's encrypted disk after a power cycle, your phone uploads a sealed blob. The blob is encrypted to a key only your phone holds; we cannot open it. We hand it back to your server when your phone authorizes the unlock. We retain it as long as you have a paired server.
2.3 Push notification tokens (optional)
If you opt into phone push notifications (server-online, app alerts, security prompts), we store the APNs / FCM token your phone provides. We send these tokens straight to Apple / Google when delivering a notification; we do not retain notification content beyond the time it takes to enqueue.
2.4 Billing data (only if you pay)
Flagship does not sell anything today, so we collect no billing data. The rest of this section will apply only if we start offering hardware or paid add-ons.
If you buy hardware or subscribe to an add-on, Stripe handles payment and we receive: a Stripe customer ID, the last four digits of your card, your billing country, and the line items you bought. We never see the full card number. For shipping hardware we also store your shipping address until the box is delivered, then it's deleted within 90 days.
2.5 Logs (operational, short retention)
| Source | What's logged | Retention |
|---|---|---|
Cloudflare (flagshipserver.com) |
IP, request path, status code, user agent | 30 days |
Our relay on Fly (flagship.services) |
No per-connection log. In-memory counters (bytes, streams, and destination names for box-initiated AI calls), written as totals every 15 minutes with no account or box; an error line naming a box's address when its connection is held too long | Fly's log buffer; the counters are not kept |
| Fly (the hosting platform) | Whatever connection metadata Fly itself records for its customers | Per Fly's policy; not set by us |
| Stripe | Payment events | Per Stripe's policy |
| Application errors | Stack traces, no payloads | 30 days |
2.6 Repo adaptations (anonymous, public)
When your Flagship server's AI adapts a public open-source repo so it runs on Flagship, the server shares the adaptation with us by default, so the next person can install that repo without needing AI (what a repo adapter is). You can switch sharing off on the import screen. Adaptations are public: we publish them at github.com/ibisllc/flagship-adapters, so anyone can see exactly what Flagship servers will apply. For each one we keep and publish the repo's address, the commit it was made against, the repo's license, the adaptation itself, the day it was published, and how many servers sent the identical file.
We never record who sent one: no account, server, IP address or user agent is attached or stored, and nothing in the operational logs in §2.5 is joined to it. Until it is published, an adaptation waits with us, with only the day it arrived; we publish in daily batches, dated to the day. We only keep adaptations of public repos under an open-source license, after checking them; when the optional automated review is on, the adaptation (never anything about you) is sent to Anthropic for that check. When we refuse an adaptation for a reason it can fix, your server's own AI may fix it and send it again. A repo owner can have their repo added to our public do-not-adapt list; see /adapters.
When an adaptation fails to build or start during an install, your server reports which adaptation it was and whether it failed to build or to start, nothing else, so broken ones get withdrawn. You can also report a problem from the service page with a short note. We keep notes privately and never publish them; we use them only to review the adaptation (with the automated review, when it is on), and we delete them within 90 days, except for a retired adaptation (below). Please don't put anything in a note that identifies you. These reports, like adaptations, carry no account, server or address. After 3 reported problems we retire an adaptation; we keep a retired adaptation and its reports privately for up to 180 days to learn from, including a weekly automated summary, sent to Anthropic, of what went wrong, and then delete them.
2.7 What we explicitly don't collect
- The content of your TLS-encrypted traffic.
flagship.servicessees only encrypted bytes; the cert lives on your box. - Files, photos, messages, or any application data stored on your Flagship server.
- The text of Messages sent through
voi.ci. They are end-to-end encrypted (§2.11). - LLM prompts, completions, or any data you send through the BYOK provider path. Flagship Inference passes prompts through without keeping them (§2.8).
- Browsing history from the pod-resident browser feature.
- Web analytics, ad pixels, session-replay, or browser fingerprints on any of our public pages.
2.8 Flagship Inference
Flagship Inference is the built-in AI your server can use to build apps when you haven't added your own AI key. It forwards your build requests to a third-party hosted model provider chosen by us, which may change.
- We don't keep anything. No prompts and no replies. Our gateway passes each request through and only counts how much each account uses, to track its credits.
- We anonymize requests. Your account, your server and your IP address never reach the provider. It receives the request text (what you asked for and the code being built) from our address, under our account, and returns the reply.
- The provider is a third party. It handles what it receives under its own terms. We do our best to safeguard you, but we don't control the provider and aren't responsible for how it behaves.
- We may change provider at any time, based on the best offer available.
You can add your own AI key at any time, and your server uses that instead.
2.9 What our systems can see: metadata
We cannot read your content, but we do see who talks to whom, when and how much. flagshipserver.com sees account names, account and device public keys, which devices are admin devices, push tokens, each server's name, public keys, the address its heartbeat arrives from, last-seen times, running software version, health reports and the orders posted for it, per-account traffic and AI-usage counts, and the audit events your devices post. flagship.services sees, for each connection while it is open, the client's address, the name of the box asked for (TLS names are sent in the clear), the time and the bytes each way, and which boxes are online. Each box's certificate names the box, so account and box names are visible in public Certificate Transparency logs. A network between you and a box can see which box you contact. The complete list is in our metadata page.
2.10 AI calls that leave your box through our relay
By default, when your server calls an AI provider with your own key, the call leaves your box through our relay address instead of your home address. The connection is encrypted between your box and the provider: the relay cannot read it. It sees the provider's hostname and the amount of data, and it limits how many connections a box may open. We keep a list of provider hostnames boxes have reached, with daily totals; the list has no account, server or address in it. You can switch this off per key. A provider that cannot be reached this way is reported to you as an address that couldn't be reached.
2.11 voi.ci pages and Messages
If you publish a page at voi.ci/<your username>, or send or receive messages through one, this is what we handle.
- Your page is public. We store what you publish (photo, display name, bio, links, posts) and show it to anyone. It uses the same username as your apps and servers. A photo is shrunk and re-encoded on your device before upload, which drops its location and camera details.
- Messages are end-to-end encrypted. Only the sender and the page owner's devices hold the keys. We store each message sealed, and we can't read it.
- Visitors use a name made for one page. A page owner sees a visitor as, for example, "Visitor 4F3A", never their username, and a visitor's name toward one page can't be linked to their name toward another.
- What our servers see when a message is sent: that this visitor name wrote to this page, when, how big the message was, and the IP address it came from. When you sign in to message a page, we see that your account asked to message someone, and vouch for you without naming you; we don't keep a record that joins your account to the pages you write to. We could build that record if we chose to log it, and we don't. A later version may remove even that possibility.
- Messages delivered straight to the owner's phone. When the page owner's phone is online, your browser sends the message to it directly, through our relay, instead of leaving it in our mailbox. The page owner's phone then sees the IP address the message came from, the way any website you visit sees yours.
- The abuse tag. Each message carries a tag naming the sender's account, sealed to a Flagship key kept offline, on hardware keys. We open it only when someone reports that message, to act on the report. Nobody at Flagship can open tags in bulk from our servers.
- Reports. A report about a message sends us the message still sealed, the reason and the page: we learn which account sent it, not what it says. A report about a page sends the page, the reason and an optional note. We don't store the reporter's IP address. If you write to us instead, we keep your email to answer you.
- Device checks. To limit spam, the app asks Apple (App Attest and DeviceCheck) or Google (Play Integrity) to confirm it is running on a real device, the first time your account uses Messages and when it renews. A device can set up Messages for one new account a month, and a device used by a banned account can't set it up again. We store the platform, the date, a keyed hash of the app's device key (not a device identifier) and the latest check token for 30 days. Apple and Google keep two or three bits about the device (whether it enrolled this month, whether it was banned). They learn that the app checked the device, not why. Without this check (the webapp, or a device that fails it) you can still use Messages, more slowly. We never ask for a phone number.
- Notifications about a new message carry no content.
- No AI. Pages and messages never reach any AI model, ours or a provider's.
3. Sub-processors
We use the following third parties to operate Flagship. Each has its own privacy posture and applicable data-protection agreements.
| Vendor | Used for | Region |
|---|---|---|
| Cloudflare | Worker, D1, R2 (sealed blobs, screenshots, repo adaptations waiting to be published, voi.ci pages and sealed messages), DNS | Global edge |
| GitHub | The public repo of shared repo adaptations (no personal data) | US |
| Fly.io | Stateless tunnel hub on flagship.services | US/EU regions |
| Stripe | Payments and subscriptions, only if we ever start selling something (§2.4) | US/EU |
| Apple (APNs, App Attest, DeviceCheck) | iOS push delivery; device checks for Messages (§2.11) | US |
| Google (FCM, Play Integrity) | Android push delivery; device checks for Messages (§2.11) | US |
| Let's Encrypt (ISRG) | TLS certificate issuance | US |
| A third-party hosted model provider chosen by us, which may change | Flagship Inference only: receives anonymized request text (no account, server or IP address) and returns the reply (§2.8) | Depends on the provider |
| Anthropic | Checks shared repo adaptations, and summarizes retired ones, when that review is on (§2.6) | US |
If you BYOK (bring your own key), prompts go from your daemon to the provider you chose, inside an encrypted connection that, by default, passes through our relay without being readable (§2.10). The provider, not us, receives and handles them; we are not a sub-processor of their content.
4. Retention
- Username and public key: kept as long as your account exists. On deletion, removed within 30 days; the public-key fingerprint may persist in revocation lists.
- Sealed blob: kept while you have a paired server; removed within 30 days of server unpairing.
- Push tokens: kept while you opt in; removed when you opt out or the token expires.
- Billing data: kept for 7 years for tax compliance after the last transaction.
- Shipping addresses: kept until delivered, plus 90 days for return-window handling.
- Logs: 30 days, then aggregated counters only.
- Repo adaptations: published, and kept public; our own copy of the file is deleted once it is published, usually within a day. Taken out of the index when the repo's owner asks; git history keeps earlier versions. They carry no personal data.
- voi.ci page: kept while it is published. When you change it, pieces no longer used are deleted within 30 days; when you delete your account, it is deleted at once.
- Messages: sealed messages are deleted 180 days after they arrive, or when the page owner's account is deleted. Copies on your own devices stay until you delete them.
- Unpublished page changes waiting for an admin device: 30 days.
- Device check tokens: 30 days. The enrollment record (platform, date, keyed hash) is kept while the account uses Messages.
- Abuse reports: kept while open, then one year after they are resolved. Bans and takedowns are kept while the account exists.
- Problem reports on adaptations: notes deleted within 90 days. For a retired adaptation, its private copy and its reports are deleted 180 days after it was retired.
5. Legal basis (GDPR)
If you are in the European Economic Area, the United Kingdom, or Switzerland, we process your personal data on the following bases:
- Contract: account data, sealed blobs, server provisioning, billing: necessary to provide what you signed up for.
- Legitimate interest: 30-day operational logs to keep the service running and abuse-resistant; the device checks, limits, reports and bans that keep Messages free of spam and abuse (§2.11). We've balanced this against your interests; you can object.
- Consent: push notifications, marketing email (if any). Withdrawable from the phone app or by emailing privacy@flagship.services.
- Legal obligation: tax records on billing data.
6. Your rights
Depending on where you live, you have some or all of the following rights regarding personal data we hold about you:
- Access: a copy of what we have. We'll respond within 30 days.
- Correction: fix anything inaccurate.
- Deletion: ask us to delete your account and data; we'll do so within 30 days, except where law (mostly billing records) requires longer retention.
- Portability: a machine-readable export of your account data.
- Objection: object to processing based on legitimate interest.
- Restriction: ask us to pause processing while a dispute is resolved.
- Withdraw consent: at any time, for processing based on consent.
Mail privacy@flagship.services. We'll verify by asking you to sign a challenge with your account key. No friction theatre.
California (CCPA / CPRA)
California residents have the rights above plus the right to know what categories of personal information we have collected, sold, or shared in the past 12 months. For Flagship, the answers are: we have collected the categories listed in §2; we have not sold or shared personal information; we do not use personal information for cross-context behavioral advertising. We do not knowingly collect personal information from children under 13.
Do Not Track and Global Privacy Control
We don't track you across the web. We honor GPC by default, mostly because there's nothing to honor; we don't have analytics enabled.
7. International transfers
Cloudflare, Fly, Stripe, and the rest of our sub-processors operate globally. Where data crosses jurisdictions, we rely on Standard Contractual Clauses (EU) or the equivalent. Your sealed blob is, structurally, opaque to every jurisdiction it passes through.
8. Security
The architecture, threat model, and bug-bounty pointer live at /security. The summary: we hold standard secrets (API keys to our sub-processors) in encrypted vaults, rotate quarterly, scope per-environment. Internal access to operational systems requires hardware-backed FIDO2.
If we ever experience a personal data breach affecting you, we'll notify you within 72 hours of becoming aware, and we'll publish a postmortem with timeline and remediation. We'll also notify any supervisory authority required by law.
9. Children
Flagship is not directed at children under 13. If you believe a child has provided personal data to us, mail privacy@flagship.services and we'll delete it.
10. Changes to this policy
If we change this policy materially, we'll update the "Last updated" date at the top, post a note in the dashboard, and email account-holders affected. Older versions stay accessible through the GitHub mirror.
11. Contact
Privacy questions: privacy@flagship.services.
Abuse on a *.flagship.services subdomain or a voi.ci page: /abuse.
Security disclosures: /security#report.
Postal: Flagship, address available on request to the address above.
If you're in the EU and you're not satisfied with our response, you have the right to complain to your local supervisory authority.