Security

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.
Security policies: Shorebird publishes its security policies in the compliance section of its handbook, including access management, change management, incident response, business continuity and disaster recovery, and vulnerability management.
Questionnaires, document requests and anything else: email contact@shorebird.dev.

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 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.
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.
Is data encrypted?	Yes, in transit (HTTPS only) and at rest. See 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.
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.
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.
How do we delete our data?	Delete your account from the console. See 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 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.
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.
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 is the legal document for what Shorebird collects and the vendors it uses, and you can sign its Data Processing Agreement 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 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 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).
Signing keys: for managed 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 and service accounts you create can publish a release or patch for your app, and only with a role that allows it. See Organizations 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.
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, with SCIM provisioning 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 and, on Enterprise, Enterprise Roles.
CI and automation: service accounts with their own role and revocable API keys, or 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.

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 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 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. 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.

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 contact@shorebird.dev with the steps to reproduce the problem. Shorebird doesn’t run a bug bounty program. The Vulnerability Management Policy describes how reports are handled.

Terms

Your use of Shorebird is governed by its Terms of Service. The privacy policy and Data Processing Agreement are linked above.