Questions, in plain English.

Any x86_64 machine with at least 2 GB of RAM, 32 GB of disk, and a working ethernet port. An old laptop, a NUC, an Optiplex from 2014. All fine. (You can also host a server on a computer you already use, Apple-silicon Macs included, from Flagship Studio.) The builder handles the OS for you, so you don't need to know or care what it runs.

About ten minutes from inserting the USB stick to a real green padlock at you.flagship.services. Most of that is the kernel booting and Let's Encrypt issuing your cert. To make the stick, pair the app directly with Flagship Studio; your phone sends the signed recipe and Studio does the rest.

The first time your new server asks to be approved, your phone keeps that server's own key and checks everything against it from then on. If the machine has a screen, it shows a six-digit code, and your phone shows the same code above Approve: if they don't match, don't approve. Your recipe also carries a one-time secret, so a server that was not built from it is refused. When Studio hosts the server on your computer, it checks the code for you. Later, if a server's key ever changes, the app refuses it and tells you.

On Android, yes. Plug a USB stick into your phone with an OTG adapter and choose to write the installer on this device when you create a server. The app writes a stock Debian installer that anyone can rebuild and check byte for byte, then adds your phone-signed recipe. The iPhone app can't write the stick; on iPhone, use Flagship Studio on a computer.

Yes. The installer formats the target disk, sets up LUKS full-disk encryption with a key only your phone can release, and lays down a hardened Linux base. Anything that was on the disk before is gone. The installer asks twice and shows you the device path; we try hard not to surprise anyone.

No. Your box opens an outbound WebSocket to flagship.services; that's the tunnel. No port-forwarding, no dynamic DNS, no router config. CGNAT is fine. The only requirement is that outbound TCP/443 works, which it does on every consumer ISP.

Not really, but you have options. The phone is the trust root in the strong-security path; there's no email-and-password to fall back to. If you don't want to use a phone, the installable web app at webapp.flagshipserver.com works as a peer device (passphrase + WebAuthn instead of Secure Enclave). It's a weaker key-storage trade-off but it's an account you fully control.

Open Flagship Studio on your computer. It shows a QR and a short code. In the mobile app, choose Add server → Pair with Studio, scan or enter the code, and compare the security code on both screens. Your phone signs the recipe and sends it directly to Studio; the pairing session is short-lived and single-use. The webapp offers a signed recipe download instead.

Not yet. The USB installer is for x86-64 PCs, and we don't support Raspberry Pi or other ARM boards. Flagship does run on arm64 in one way: Flagship Studio on an Apple-silicon Mac hosts your server in an arm64 virtual machine.

Not the content of your data: files, messages, app data and AI prompts never reach us in a readable form. TLS ends on your own box, against a Let's Encrypt certificate whose private key only your box holds, so flagship.services sees encrypted bytes go past on a TCP pipe. What we can see is metadata: that your account exists, which servers it has and when they are online, roughly how much traffic they carry, and the other items listed under "What does Flagship the company actually store?" below. Because we run the flagship.services DNS zone we could also obtain a certificate for a box's name; the apps pin your box's own signed certificate and would refuse it, and any such certificate would be visible in public Certificate Transparency logs, but a plain web browser would not notice. The full list of who sees what is in our metadata page.

Your username and your devices' public keys; each server's name, public keys, the address its heartbeat arrives from, last-seen times, health reports and the orders sent to it (updates, backup policy, moves); a sealed LUKS-unlock blob (encrypted to your phone); push-notification tokens; the audit events your devices post; and per-account counts of traffic and AI usage. We also keep one list of the outside AI hosts boxes have reached, with totals and no account or box. No file content, no prompts, no chats, no service traffic. The full inventory lives in /privacy.

Game over for that account, the same way it's game over for your bank app. The phone is the trust root; a compromised root can sign whatever it wants. That's why the keys are wrapped by a key held in the phone's secure hardware (the Secure Enclave on iPhone, the hardware-backed Keystore on Android), and sensitive actions such as approving a server's start or signing as an admin ask for your biometric. While the app is unlocked, some keys are held in the phone's memory, so a phone that is already hacked and unlocked is not protected. If you suspect a compromise, use any other paired device to revoke the phone's identity key.

Standard primitives only: Ed25519 signatures, X25519 + AES-256-GCM for sealed blobs, HKDF-SHA-256 for key derivation, LUKS2/argon2id for the disk. Real Let's Encrypt certificates, requested by your box itself, for transport. Since 0.3, servers and phones also hold ML-DSA-65 keys beside their Ed25519 keys, and a hybrid quantum-safe channel (ML-KEM-768 with X25519) is built, with an opt-in setting on iPhone and Android; that work is pending external review. If we ever invent our own crypto, please report it as a bug.

Yes. The protocol, daemon, image-builder, and clients are at github.com/ibisllc/flagship under BUSL-1.1, which converts to Apache 2.0 in 2030. The boot image is reproducible: you can check that its bytes match stock Debian. The server software installs from a package signed by Flagship's maintainers.

They can compel us to hand over what we have, and what we have is account and server metadata (see above), a sealed blob, and routing records. We can't decrypt your traffic because we don't terminate it. We can revoke the routing entry for your subdomain (which takes your services offline); that's a power we have and we'd resist abusing. We'll publish a transparency report annually once we have any requests to report.

Cloudflare gets normal request logs (IP, path, status) for flagshipserver.com on a 30-day window; we don't extend them. Our relay on flagship.services writes no per-connection log: it keeps counters in memory (totals every 15 minutes) and shows an error line only when a box's connection is parked too long. Its hosting platform (Fly) may keep connection metadata under its own policy. Your daemon logs locally on your box and never ships those logs anywhere. We don't run analytics, ad pixels, or session-replay on the marketing site or the dashboard.

You describe what you want in plain language ("a tracker for which houseplants I've watered, push me when one's been thirsty 5+ days"). An AI model writes the code: your own provider key, Flagship Inference, or a model running on your own server. Your daemon builds it, gives it what it asked for (a Postgres database, a files folder, push), and runs it at plant-water.you.flagship.services. About 90 seconds. You can edit the code if you feel like it.

Yes, two ways. Invite people to use one app with a link you create on your phone; each person joins with their own key and you set their rank. Or share the whole server with another account, to view it or to co-manage it (a co-manager can never destroy it). There is no central database: the lists live on your servers, and changes are signed by your admin device.

The data-layer is per-service and per-user-namespaced: each app gets its own Postgres database and its own files folder, runs in a sandbox (gVisor), and can reach the internet only at hosts you approve. A service for "plant watering" can't read your photos. Nothing stops a malicious service from being terrible inside its own scope, which is why you should think before installing one.

Whichever you've configured: bring your own key for Anthropic, OpenAI, Google, OpenRouter or any OpenAI-compatible API. Keys live on your daemon, encrypted at rest. By default your box reaches the provider through our relay address, which carries the encrypted connection and sees the provider's hostname and the amount of data, not the prompts; you can turn that off per key. With no key, building an app uses Flagship Inference, our built-in AI: it passes requests to a third-party model provider without keeping them (see /privacy).

Yes. Open Local AI from your server's page and download a model. Your apps and builds can then use it, and your prompts and data never leave your server; downloading the model is the only time the server contacts the model's host. It runs on the processor, or on a graphics card once that model of card has been qualified. You can also train a small model on an app's sample data. This is early: small models only.

Only if you say so. An app that needs a graphics card waits for your approval, signed from your admin device, and you can withdraw it later. Flagship also gives a card to an app only once that model of card has passed our hardware tests; until then, apps that need one tell you they can't run yet.

Only if you choose it. Each app has an update mode: manual (the default, you approve every update), staged (a checked update waits a week) or automatic. The automatic modes only take updates from the same publisher that ask for no new permissions; anything else waits for you.

Yes. Uninstall drops its container, its Postgres database, its files folder and its access list. You can keep a snapshot before uninstall if you want to come back to the data later.

A simple public page at your username on voi.ci: a photo, a name, a short bio, links and posts. You make it in the Messages tab of the app, and only an admin device of your account can publish it. Anyone can see it, and it uses the same username as your apps and servers, so people can connect them.

If you turn on Accept messages, anyone with a Flagship account can write to you from your page. You see each of them under a name made for your page, like "Visitor 4F3A", never their username, and you can rename them for yourself. New conversations wait under Requests until you reply or accept them.

No. Messages are end-to-end encrypted, with post-quantum encryption, to your devices and the sender's. We see that someone wrote to your page, when and how much, not what they said. Each message carries a sealed tag naming the sender's account, which we open only if you report that message. The privacy policy has the full list.

In a conversation, tap Report or Block. A blocked visitor isn't told, and their messages stop reaching you. Anyone can report a page with the Report this page link at the bottom of it, or by email (see /abuse). A person at Flagship reviews every report; we can take a page down and stop an account from sending messages.

To slow spam without asking for your phone number. The first time you use Messages, the app asks Apple or Google to confirm it runs on a real device. One device can set up Messages for one new account a month. Apple and Google learn that the app checked the device, not why. Without the check (for example in the webapp) Messages still works, more slowly.

It keeps running, and so do your services, until its certificate runs out (certificates last about 90 days). Several things need us: routing through flagship.services (the tunnel hub is ours), renewing the certificate (our DNS zone is used for the challenge), setting up a new server, pairing a new device, account recovery and any routing change. The code is open, so someone could run their own copies, but we have not built a handover for that, and we don't promise one.

Your phone can still find your server on your home network and check the server's own key. From there you can see its status and its apps, start, stop or restart an app, restart or shut down the server, and make a backup and save it to your phone. Every action is signed by your phone and checked by the server. This works while the server is running: a server that restarts still needs us to unlock its disk, and creating an account, adding a device or recovering an account still need us. A web browser can't do this; it takes the iPhone or Android app.

The data is on your disk; it was never anywhere else. The identity is your phone's keypair; it doesn't depend on us being alive. The username at flagshipserver.com goes away if the company does, but the underlying public key is yours. Keep a backup of your account key and of your server (Back up now) so you can rebuild elsewhere.

Yes. BUSL-1.1 with a Change Date of 2030-05-03: even if the company evaporates tomorrow, the entire codebase becomes Apache 2.0 in 2030 by license, and the GitHub mirror stays up regardless.