Security
This is our public security policy for the Shorebird system and products. This document exists both for education of our employees as well as for reference by our customers. Pull requests are welcome.
Authorship and change history for this policy are visible in the git history of this document.
Management reviews this document annually. Last Reviewed: April 2025.
Changes or exceptions to these policies should be reviewed by the CEO.
About Shorebird
Section titled “About Shorebird”Shorebird is a software application. Most of our code is open source and publicly reviewable on GitHub. We use Google Cloud for the bulk of our infrastructure.
Shorebird takes security very seriously. We take several steps to make sure that we protect the data you give us, only require data that is absolutely necessary for product functionality, and that only you can publish changes to your account and applications.
Shorebird only offers a hosted service at this time. We do not currently offer on-prem or cloud-prem solutions.
Company Security Policy
Section titled “Company Security Policy”This document is focused on the specifics of the Shorebird system and product. If there are questions that relate to the overall company security policy please refer to the Security section in our Handbook.
Throughout this document we will refer to the following terms:
- Customer / you: A user of Shorebird.
- End User: A user of a Customer’s application.
Acceptable Use
Section titled “Acceptable Use”Use of Shorebird is governed by our Terms of Service. We have logging and alerting in place to ensure that our service is not used for malicious purposes or such that would disrupt the service for other users.
Infrastructure
Section titled “Infrastructure”Shorebird is hosted on Google Cloud. We use Google Cloud’s security features to secure our infrastructure. We have a dedicated VPC for our infrastructure.
Currently Shorebird only uses Google Cloud’s Iowa region. We have plans to expand to other regions in the future for our international customers.
Shorebird uses Google Cloud’s managed services where possible. We do not manage custom versions of software or operating systems, but instead rely on Google Cloud to manage and update these services on a daily basis. For example, our application end points use Google Cloud Run which is a managed service that lives no longer than an hour, allowing Google to manage the underlying infrastructure including patching continuously. Other parts of our infrastructure are similar.
Architecture
Section titled “Architecture”We’ve written more on the architecture of Shorebird in our architecture documentation.
Shorebird Servers
Section titled “Shorebird Servers”shorebird tools communicate with Shorebird’s cloud on your behalf. Shorebird
exclusively uses public cloud infrastructure and does not maintain our own
custom servers. We use Google Cloud and Cloudflare for all of our publicly
accessible endpoints.
The following URLs are used by Shorebird.
- https://console.shorebird.dev — used to interact with Shorebird’s services via the web.
- https://api.shorebird.dev — used by the shorebird command line tools to interact with the Shorebird servers as well as the Shorebird updater on users’ devices to check for updates.
- https://download.shorebird.dev — used by the shorebird command line tool to download Flutter artifacts for building releases and patches.
- https://storage.googleapis.com — used by the shorebird command line tool to upload and download release and patch artifacts, and by the Shorebird updater on user’s devices to download the patches.
- https://cdn.shorebird.cloud/ — used by the Shorebird updater when downloading patches to a user’s device.
Because all access done via https to public cloud infrastructure, typically no specific access rules are required to access Shorebird servers from within a company network.
Product Access Control
Section titled “Product Access Control”Shorebird accounts are managed through Google or Microsoft SSO (OAuth). We intentionally do not support other access methods and do not store passwords for our users.
Shorebird accounts provided role-based access control on a per-application basis. We have three roles: Owner, Admin, and Developer which are described in our Organizations product documentation
Production Access
Section titled “Production Access”We use Google Cloud IAM for access control and Google Cloud Logging for logging.
A small number of engineers have access to production systems, for which we have a dedicated machine for access. Production changes are all done via CI/CD pipelines, as detailed in the Change Management section.
We have an additional (read-only) admin layer to a subset of our production systems for monitoring and support purposes.
Network Access
Section titled “Network Access”Shorebird is a web application. We use HTTPS for all communication between our application and our customers. We use Google Cloud’s managed SSL certificates for this.
Use of Shorebird requires access to the following web addresses:
api.shorebird.devconsole.shorebird.devstorage.googleapis.comcdn.shorebird.cloud
Only the https port should be needed for access to Shorebird.
See also https://docs.shorebird.dev/faq/#can-i-use-shorebird-in-my-country.
User Access Review
Section titled “User Access Review”We review all user access to our systems periodically, as well as as part of an employee joining or leaving the company. All access to Shorebird systems is gated through Google SSO including required two factor authentication.
Network Security
Section titled “Network Security”Both our application and our infrastructure are hosted on Google Cloud. We use Google Cloud’s network security features to secure our infrastructure, including restricting all public access to our infrastructure outside of our application endpoint.
We have dedicated machines for access directly to our production environment, access to such is restricted to a small number of engineers and is logged.
Intrusion Detection / Prevention / Monitoring
Section titled “Intrusion Detection / Prevention / Monitoring”We rely on Google Cloud network security for network-level intrusion detection. We do log all actions within our systems and do regularly review these logs as well as maintain alerting which is delivered to our engineering teams, both for our web products as well as our backend database and servers.
Change Management
Section titled “Change Management”Code Reviews
Section titled “Code Reviews”All code should be reviewed by at least one other engineer before being merged. We have branch policies in place on all of our repositories to ensure such. This is done in service of security, but also in service of code quality. We believe that code reviews are the best way to ensure that code is secure, maintainable, and understandable.
Dependencies
Section titled “Dependencies”We keep all of our dependencies up to date. All of our repositories are expected to use Dependabot to automatically open pull requests for updates to our dependencies.
All of our production code has 100% test coverage. We have automated tests in place to ensure that changes do not break our application. Debugging or non-production code is not required to have 100% test coverage.
Deployment
Section titled “Deployment”All changes to production are deployed through a CI/CD pipeline. We use GitHub Actions for this. We have a staging environment that is used for testing changes before they are deployed to production.
Our CI/CD pipeline runs tests, linters, and other checks before deploying to production. Our CI/CD pipeline is configured with unique service accounts that have the minimum permissions necessary to deploy to production.
Rollbacks
Section titled “Rollbacks”We have the ability to rollback changes to production. Typically we execute a rollback via a revert commit in our codebase and a new deployment, however we also have the ability to rollback individual services in our infrastructure to previous versions if necessary.
Incident Response
Section titled “Incident Response”We have a private playbook for incident response. We have logging and alerting in place to detect and respond to incidents. We have both dedicated private channels on Discord for response as well as back-up text communication pathways as well as phone numbers for all engineers.
We do not currently have separate incident tracking beyond our public GitHub. We always notified all customers when affected by incidents (security or otherwise) via their billing email address in the past and will continue to do so going forward.
Post Mortem’s
Section titled “Post Mortem’s”We have a post mortem process in place for incidents. We prepare a post-mortem for all incidents within 48 hours of their occurrence. We use these post mortem’s to improve our systems and processes. We do not currently share our post mortem’s publicly, although we are considering doing so in the future.
Data Usage & Security
Section titled “Data Usage & Security”Data Privacy
Section titled “Data Privacy”See our privacy policy: https://shorebird.dev/privacy
The information we collect from you is used to provide the service for you. We do not sell or share your information with third parties, except as required by law. Your data is stored in association with your account and deleted when you delete your account.
Shorebird does not process, transmit or store personally identifiable information for our customers’ end users. Additionally, we take care to store as little data from our customers (you) as possible.
Data Retention
Section titled “Data Retention”We retain customer data for as long as you have an account with us. Customers are able to access and delete their data at any time. We retain aggregated, anonymized data for analytics purposes beyond termination of your account.
Customers can delete almost all information in their account by hand, however deleting the final database row requires contacting support at this time: https://docs.shorebird.dev/uninstall/
See our privacy policy for more information: https://shorebird.dev/privacy
Data Security
Section titled “Data Security”Shorebird uses Google Cloud’s managed services for backups. This data (as well as all data in Google Cloud) is encrypted at rest. https://cloud.google.com/docs/security/encryption-in-transit https://cloud.google.com/docs/security/encryption/default-encryption
We are not aware of any past data breaches for Shorebird of any form. In the event of such we will notify all customers promptly unless otherwise required by local law enforcement.
Data Separation
Section titled “Data Separation”Shorebird does not currently use per-tenant data storage. We use a single, secured, non-publicly-reachable database (AlloyDB) for all system data. We use a variety of private cloud buckets for storing customer data files, which are segmented currently based on purpose rather than customer/tenant.
As noted elsewhere, we do not store any information about your customers.
Customer data we store for you is only your email addresses and the data files you have created within our service. Stripe stores your billing information on our behalf.
Confidentiality
Section titled “Confidentiality”Our Terms of Service and Privacy Policy cover our obligations to you as our customer.
Customer Data (data about you as a user of Shorebird)
Section titled “Customer Data (data about you as a user of Shorebird)”In general we do not access customer data unless required as part of providing you support or monitoring the service for usage and security.
We treat customer data as confidential. We have logging in place to detect unauthorized access to customer data. Customer data may be accessed by employees as part of providing support to you.
We do not share customer data with third parties except as required by law. We have a few third party services that we use to run our business, see our privacy policy for our list of vendors: https://shorebird.dev/privacy/
We try to store very little data for or about our customers. Examples of customer data we store include:
- Email address and Name
- Stripe Customer ID (we do not store payment information)
- Built applications archives (e.g. .xcarchive, .aab for Releases and Patches)
- Release Metadata (e.g. flutter version, xcode version, java version, etc.)
Shorebird servers never see or store your source code. All shorebird commands
run locally on devices you control and only upload the built application
archives (same binaries you distribute to stores and your users) to our servers
for your later use or distribution.
Google Cloud encrypts all data at rest by default.
End User Data (data about Shorebird’s customers’ end users)
Section titled “End User Data (data about Shorebird’s customers’ end users)”Shorebird does not process, transmit or store personally identifiable information for our customers’ end users. We do not have access to end user data. Customer security forms often ask for information about how we handle end user data. We do not handle end user data.
Some regions consider IP addresses to be personally identifiable information, Google Cloud does record IP addresses in logs. We do not access these IP addresses in logs for any purpose other than security and monitoring.
Shorebird’s product allows you, and only you, to update the code of your application on end user devices. We do not collect or wish to collect any information from these users or devices.
Third-Party Assessments
Section titled “Third-Party Assessments”We have no third party security, network or otherwise assessments to share at this time. Some of our larger customers have performed their own audits of our provided infrastructure and when appropriate we have made adjustments based on their feedback.
As noted in other parts of this document, we intentionally do not run our own servers, or build our own network infrastructure, rather we rely on Google and Cloudflare servers and networks to reduce our total exposure and upgrade/maintenance burdens.
Bug Bounty
Section titled “Bug Bounty”We do not currently offer a bug bounty program. We welcome reports of security vulnerabilities.
contact@shorebird.dev is the best way to reach us. We will respond to reports in a timely manner.