--- title: "Security" description: "How Shorebird protects your account, your builds and your app's updates, what it stores and where, and how to get documents for a security review." --- This page describes how Shorebird handles your data and protects the patches it delivers to your app. It’s written for the developers who use Shorebird and for the security and procurement teams who review it. ## For security and vendor reviews If you’re reviewing Shorebird as a vendor: * **Compliance status and documents**: see Shorebird’s [trust center](https://trust.shorebird.dev). * **Security policies**: Shorebird publishes its security policies in the [compliance section of its handbook](https://handbook.shorebird.dev/compliance/), including access management, change management, incident response, business continuity and disaster recovery, and vulnerability management. * **Questionnaires, document requests and anything else**: email . The questions reviewers usually ask, with short answers: | Question | Answer | | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Does Shorebird see our source code? | No. The CLI builds your app on your machine or CI runner and uploads only the built app files. See [What Shorebird stores](#what-shorebird-stores). | | What does Shorebird collect from our app’s users? | No names or accounts from your app, no device identifiers and no location. Your app sends an anonymous per-install identifier and the details needed to pick a patch and count installs. See [Data from your app’s users](#data-from-your-apps-users). | | Where is our data stored? | In Google Cloud in the United States. Patches are delivered through Cloudflare’s network. See [Where your data is stored](#where-your-data-is-stored). | | Is data encrypted? | Yes, in transit (HTTPS only) and at rest. See [Encryption](#encryption). | | Can someone push code to our app through Shorebird? | Publishing a patch takes a member or service account of your organization with a role that allows it. Patch signing, on by default, protects against anyone between your users and Shorebird; signing with your own key also protects against stolen Shorebird credentials. See [Protecting your app’s updates](#protecting-your-apps-updates). | | How do our people sign in? | Google or Microsoft sign-in, or your identity provider over SAML on the Enterprise plan. Shorebird stores no passwords. See [Access to your account](#access-to-your-account). | | Is there a self-hosted or on-premises version? | No. Shorebird is a hosted service only. | | Which hosts does our firewall need to allow? | See [Hosts Shorebird uses](/system/firewalls-and-mirrors/#hosts-shorebird-uses). | | How do we delete our data? | Delete your account from the console. See [Deleting your data](#deleting-your-data). | ## What Shorebird stores Shorebird stores what it needs to run your account and deliver your patches: * **Your account**: your email address and display name, and your organizations, apps, members and roles. When you sign in with Google or Microsoft, Shorebird asks only for your email address and the account’s identifier. * **Your builds**: the release files the CLI uploads (such as `.aab`, `.apk` and `.xcarchive`), the patches it builds from them, and details of each build, such as its Flutter and Xcode versions. See [The CLI: data from you and your team](/system/what-shorebird-collects/#the-cli-data-from-you-and-your-team) for everything the CLI sends. * **A record of changes**: who changed what in your organization and when, with the IP address and user agent of the request. On the Enterprise plan you can read it as an [audit log](/enterprise/audit-logs/). * **Patch statistics**: a record of each patch check and patch event from your app, with its anonymous install identifier, which the console shows you as counts. See [Data from your app’s users](#data-from-your-apps-users). * **Product usage**: how you use the console, and when releases and patches are created, through PostHog. Console session recordings mask what you type and email addresses. * **Billing**: Stripe processes payments and holds your card details. Shorebird keeps a copy of your Stripe billing records, such as your billing name, email and address, subscriptions and invoices. Shorebird never receives your source code. Every `shorebird` command runs on your machine or CI runner, and uploads only built app files. Shorebird’s [privacy policy](https://shorebird.dev/privacy/) is the legal document for what Shorebird collects and the vendors it uses, and you can sign its [Data Processing Agreement](https://shorebird.dev/dpa/) to cover your app’s users’ data. ## Data from your app’s users The Shorebird updater in your app sends Shorebird what it needs to deliver the right patch and to report how your patches are doing: * When it checks for a patch: your app ID, the release version, the platform and CPU architecture, the track, the patch it’s running, and an anonymous install identifier, a random value generated when the app first runs. * When a patch downloads, installs or fails: your app ID, the release version, the platform and CPU architecture, the install identifier, the patch number and the time, and for a failure a short error message. Releases built with Flutter 3.47.7 or newer replace the app’s file paths in the message with placeholders; older releases send them as they are, and on desktop platforms a path can include the user’s OS user name. It sends no names, account or user IDs from your app, device identifiers, device model, location or app data. Patch checks and patch events aren’t stored with the device’s IP address. Like any web service, the request logs Google Cloud and Cloudflare keep for operating and securing the service record the IP address a request came from. [What Shorebird Collects](/system/what-shorebird-collects/) lists every field, why it’s sent, and the open source code that sends it. ## Where your data is stored Shorebird stores your data in Google Cloud, in the United States: your account, your release and patch files, and your patch statistics. Your app downloads patches from `cdn.shorebird.cloud`, which Cloudflare serves from its global network. Shorebird doesn’t offer a choice of region. Product usage data is held by PostHog in the United States, and billing data by Stripe; the [privacy policy](https://shorebird.dev/privacy/) lists every vendor. ## Encryption * **In transit**: Shorebird’s hosts serve everything over HTTPS, and redirect or refuse plain HTTP. Shorebird’s API accepts TLS 1.2 or newer. * **At rest**: Google Cloud encrypts all stored data by default (see [Google Cloud’s default encryption](https://cloud.google.com/docs/security/encryption/default-encryption)). * **Signing keys**: for [managed patch signing](/code-push/guides/patch-signing/), Shorebird holds your organization’s private key in a cloud key management service, which signs patches without the key leaving it. ## Protecting your app’s updates Only members of your organization, the app’s [collaborators](/account/orgs/#per-app-collaborators) and service accounts you create can publish a release or patch for your app, and only with a role that allows it. See [Organizations](/account/orgs/) for what each role can do. On the device, your app checks every patch before installing it: * It checks that the downloaded file matches the hash Shorebird’s server sent for it, and rejects it otherwise. * If the release was built with patch signing, which is the default from Shorebird CLI 1.6.132, it also checks the patch’s signature against the public key built into the release, and refuses a patch that isn’t signed with the matching private key. With managed signing, the default, this protects against anyone between your users and Shorebird; to also protect against someone with your Shorebird credentials or control of Shorebird, sign with your own key. See [what managed signing protects against](/code-push/guides/patch-signing/#what-managed-signing-protects-against). * If a patch fails to launch, the app rolls back to the code it ran before. Release files are stored privately; the CLI uploads and downloads them through signed URLs that Shorebird’s API issues to your signed-in account. Patch files are served publicly from the CDN, like the app binaries you publish to the stores, so anyone with a patch’s URL can download it. ## Access to your account * **Sign-in**: Google or Microsoft accounts, or, on the Enterprise plan, your company’s identity provider through [SAML single sign-on](/enterprise/saml/), with [SCIM provisioning](/enterprise/scim/) to add and remove people. Shorebird doesn’t support passwords and doesn’t store any. * **Roles**: organization roles apply to every app in the organization. See [Organizations](/account/orgs/) and, on Enterprise, [Enterprise Roles](/enterprise/roles/). * **CI and automation**: [service accounts](/account/service-accounts/) with their own role and revocable API keys, or [trust rules](/account/trust-rules/) that let a GitHub Actions workflow sign in without a stored key. * **Audit log**: on the Enterprise plan, the console and API show who did what in your organization, and your SIEM can collect it. See [Audit Logs](/enterprise/audit-logs/). ## Hosts Shorebird uses Everything Shorebird runs is on Google Cloud and Cloudflare, and is reached over HTTPS on port 443. Shorebird runs no servers of its own. [Firewalls, proxies and mirrors](/system/firewalls-and-mirrors/#hosts-shorebird-uses) lists every host your development machines, CI runners and your users’ devices contact. ## How Shorebird runs the service * **Managed infrastructure**: Shorebird’s services run on Google Cloud’s managed services, so Google patches the operating systems and servers underneath them. * **Production access**: limited to named Shorebird staff, who sign in through Shorebird’s single sign-on. * **Support access**: Shorebird staff can see your account’s data to support you, and can sign in as a user, with read-only access, to help with a support request. Every such sign-in is recorded in the archive below; it doesn’t appear in your organization’s audit log. * **Changes**: code changes are reviewed before they merge, and are deployed to production by automated pipelines, which also manage the infrastructure configuration. * **Backups**: the database has continuous backups that allow recovery to any point in the last 14 days. * **Records of actions**: actions in Shorebird are also written to an archive, where each record can’t be changed or deleted for 366 days. The handbook’s [compliance policies](https://handbook.shorebird.dev/compliance/) describe the processes behind these, such as incident response and access reviews. ## Deleting your data You can delete your account yourself, from the console; see [Delete Account](/account/delete-account/). Deleting it removes your account and the organizations where you’re the only member, with their apps, releases and patches and the release and patch files. It also erases your product usage data from PostHog. You can also delete single [apps, releases and patches](/code-push/delete/). Some data stays after you delete your account: * Records of actions, kept for security and compliance: your organization’s record of changes and the archive above. They’re kept for at least 366 days, and deleting your account doesn’t remove them. * Patch statistics for deleted apps, which hold nothing about you, and about your app’s users only the anonymous install identifier and failure messages. * Billing records: your customer record and invoices, in Stripe and in Shorebird’s copy of them. * Copies of deleted release and patch files, which stay recoverable for about two weeks. * Size analyses of your releases, which break down what’s in each build. * Database backups, which can hold a copy of deleted data until they expire. ## Reporting a vulnerability Email with the steps to reproduce the problem. Shorebird doesn’t run a bug bounty program. The [Vulnerability Management Policy](https://handbook.shorebird.dev/compliance/vulnerability-management-policy/) describes how reports are handled. ## Terms Your use of Shorebird is governed by its [Terms of Service](https://shorebird.dev/terms). The privacy policy and Data Processing Agreement are linked [above](#what-shorebird-stores).