# Shorebird: over-the-air code push for Flutter apps

> Shorebird is a CLI and service that ships Dart code changes to released Flutter apps without a store resubmission. The repository is a Dart monorepo; the getting-started path lives at docs.shorebird.dev.

**shorebirdtech/shorebird** — Code Push for Flutter and other tools for Flutter businesses.

- Repository: https://github.com/shorebirdtech/shorebird
- Website: https://shorebird.dev
- Stars: 3,032 · Forks: 235
- Language: Dart
- License: NOASSERTION
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/shorebirdtech-shorebird

## What Shorebird changes about a Flutter release cycle

A Flutter app is compiled ahead of time into a native binary, so a one-line Dart fix normally means a new build, a new store submission and a review queue. Shorebird's stated purpose is to break that link for Dart code: the README describes the project as "Code Push for Flutter and other tools for Flutter businesses." The audience is teams already shipping Flutter to app stores who want a faster path for correcting logic, layout or string changes after users have the app installed.

The repository is not just the CLI. It is a monorepo, and the package table in the README lists both client-side and server-side pieces: shorebird_cli, shorebird_code_push_client, shorebird_code_push_protocol, artifact_proxy, flutter_version_resolver, jwt, redis_client, scoped_deps, stripe_api and discord_gcp_alerts. That mix tells you what kind of project this is. It is the public source of a hosted product, not a self-contained library you drop into an app. The CLI talks to Shorebird services; the services are the part you do not run yourself.

## The packages that make up the Shorebird monorepo

The split matters when you evaluate the project, because the parts have different lifetimes and different audiences. shorebird_cli is the piece a Flutter developer installs and runs. It is described as the command line that lets developers interact with various Shorebird services. shorebird_code_push_client is a Dart library for talking to the Shorebird CodePush API, and shorebird_code_push_protocol holds the shared interfaces between client and server. If you wanted to build your own tooling on top of the API rather than use the CLI, those two packages are where the contract lives.

The remaining packages are infrastructure. artifact_proxy is a Dart server that intercepts and proxies Flutter artifact requests, which is how a Shorebird-managed build can pull the right Flutter artifacts. flutter_version_resolver decides which Flutter version a project should use. jwt, redis_client and scoped_deps are exactly what their names say: token verification, Redis access and a small dependency-injection library built on Zones. stripe_api handles billing, and discord_gcp_alerts forwards Google Cloud alerts into Discord. A reader who wants to understand the update mechanism should read the first three packages. The rest describe how the company operates the service.

## Installing the Shorebird CLI and running a first release

The README does not carry install steps. It says, in one line, "Visit https://docs.shorebird.dev to get started." That is the only installation pointer in the repository, so treat the documentation site as the source of truth for the current install command, the account flow and any platform prerequisites. The repository does tell you what the CLI is called and what it does: shorebird_cli is the command line that interacts with Shorebird's services.

What the repository supports is the shape of the workflow rather than the exact flags. You install the CLI, authenticate, initialize your Flutter project so Shorebird can track it, build a release that Shorebird can map back to its own patches, and then push a patch for later Dart changes. The concrete commands for that sequence are not in the README; docs.shorebird.dev is where they are published. Do not copy a command from a blog post and assume it matches the current CLI.

The monorepo itself is a Dart workspace. If you are building Shorebird from source rather than installing the CLI, the README gives one setup command and one test recommendation. The bootstrap script runs pub get across every package:

```bash
./scripts/bootstrap.sh
```

For tests, the README is explicit that there is no local test script yet and recommends running very_good test from inside a package directory rather than the repository root, because a root-level run will pick up packages under bin/cache/flutter and some of those tests will fail. That is a real friction point for anyone planning to contribute rather than consume.

```bash
cd packages/shorebird_cli
very_good test -r
```

The README also documents a coverage path using lcov, installed with brew, and a separate dart test invocation that writes coverage/lcov.info. Both are aimed at contributors to the monorepo, not at app developers using the CLI.

## Where code push stops: native code, assets and platform channels

The README does not enumerate what can and cannot be pushed. It points at the documentation, and the repository carries a file named NOTES_ON_CODEPUSH.md at the top level, which suggests the constraints are written down somewhere other than the README. Anyone evaluating Shorebird for a production app should read that file and the docs before assuming a given change is pushable. The general boundary that follows from the project's own framing is that this is code push for Flutter, and Flutter apps contain more than Dart.

A change to a plugin, a native platform channel implementation, an Android manifest entry, an iOS entitlement or a bundled asset is not a Dart source edit, and nothing in the repository claims Shorebird handles those. If your release cadence is dominated by native changes, the CLI adds a workflow without removing the store submission. The same applies to anything that depends on the compiled binary's behaviour at the platform boundary.

The second limitation is structural rather than technical. Shorebird is a hosted service. The CLI is open source and the packages are readable, but the update path runs through Shorebird's servers, which is why the monorepo contains stripe_api and redis_client. Self-hosting is not described anywhere in the README. If your organisation cannot route release artifacts through a third-party service, this is the wrong tool regardless of how well the Dart-level patching works.

## Shorebird compared with a plain store release or a web build

The obvious alternative is doing nothing special: build, submit, wait for review, ship. That costs you the review latency on every Dart fix, but it has no service dependency, no new CLI in the toolchain, and no question about who holds the update payload. For teams with a weekly release train and few urgent fixes, the store path is simpler and the added machinery is not obviously worth it.

The second alternative is shipping the Flutter app as a web build, where you deploy a new bundle and users get it on reload. That removes the store from the loop entirely, but it changes the product: you lose the native shell, and the app must work as a web app. Shorebird's approach keeps the native binary and patches the Dart portion, which is a different trade. It preserves the app store distribution model and accepts a service dependency in exchange for faster Dart fixes. Neither is a superset of the other.

## Maintenance cadence, licensing and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-23. Releases are frequent and versioned in the v1.6.x line: v1.6.123 was tagged on 2026-09-21, v1.6.122 on 2026-09-16 and v1.6.121 on 2026-09-14. That cadence is worth noting if you pin the CLI in CI, because a pinned version will fall behind quickly and you will need a policy for when to bump it.

Licensing is unusual and worth reading carefully. The README states that Shorebird projects are licensed under either Apache License 2.0 or the MIT license, at your option, and points to a licensing philosophy page on the project's handbook. The repository root carries both LICENSE-APACHE and LICENSE-MIT, plus a COPYRIGHT file. The GitHub metadata reports the licence as NOASSERTION, which is what you get when a repository does not map cleanly onto a single SPDX identifier; the dual-licence files are the authoritative statement, not the metadata badge. This is not legal advice, and dual licensing across a monorepo can be subtler than it looks once third_party/ is involved, so have counsel read the actual files if the licence matters to your distribution.

Upgrade cost is mostly the CLI. Because the client and protocol packages are versioned together in the same repository, a CLI upgrade can move the API contract, and any tooling you built against shorebird_code_push_client or shorebird_code_push_protocol needs to track it. Budget for that if you plan to use the libraries directly rather than only the CLI.

## Conclusion

Adopt Shorebird if you ship Flutter apps and want to correct Dart-level bugs without waiting on store review, and you accept that native code and asset changes still require a full store release. Do not adopt it if your release process cannot tolerate a hosted service holding your update artifacts, or if your app's critical paths sit in platform channels and plugins. Before committing, check docs.shorebird.dev for the current account and pricing terms, confirm the CLI version you install (v1.6.123 was tagged on 2026-09-21), and verify the licence files in the repository root against your own legal review.

## FAQ

### How do I install the Shorebird CLI?

The README does not include install instructions. It says to visit https://docs.shorebird.dev to get started, and that site is where the current install steps live.

### How do I use Shorebird with a Flutter app?

The repository describes shorebird_cli as the command line that lets developers interact with Shorebird's services, and the README sends readers to docs.shorebird.dev for the actual workflow. The repository also lists shorebird_code_push_client and shorebird_code_push_protocol as the libraries that talk to the CodePush API.

### Is Shorebird open source?

The source for the CLI, the client libraries and the supporting services is in this public monorepo. The README states the projects are licensed under either Apache License 2.0 or the MIT license, at your option, with LICENSE-APACHE and LICENSE-MIT in the repository root.

### Is Shorebird free?

The README does not state pricing. The monorepo includes a stripe_api package described as a Dart library for interacting with Stripe, which indicates billing is part of the hosted service, but no free or paid tier is documented in the repository.

### What is Shorebird Code Push for Flutter?

The repository describes itself as "Code Push for Flutter and other tools for Flutter businesses." The CLI interacts with Shorebird services, and the code push client and protocol packages define how a Dart application talks to the Shorebird CodePush API.

### What does the word "shorebird" mean?

That question is about the bird, not this project. Shorebird here is the name of a Flutter code push tool; the README gives no definition of the word itself.

## Sources

- [Issues](https://github.com/shorebirdtech/shorebird/issues)
- [Project website](https://shorebird.dev)
- [README](https://github.com/shorebirdtech/shorebird/blob/main/README.md)
- [Releases](https://github.com/shorebirdtech/shorebird/releases)
- [shorebirdtech/shorebird on GitHub](https://github.com/shorebirdtech/shorebird)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/shorebirdtech-shorebird