Upgrading

Review upstream changes and migrations while preserving product settings, resource identity, and data.

Upgrade with Git

Flare is an independent source repository. Product branding, configuration, and business code diverge from upstream over time. Compare and merge rather than overwriting a deployed project with a fresh download. Record the current commit and target and save local work first.

Inspect upstream changes

If upstream is already configured:

git fetch upstream
git log --oneline HEAD..upstream/main
git diff --stat HEAD...upstream/main
git switch -c chore/flare-upgrade

Choose the actual available update branch; do not assume a development branch has reached main. After review, merge or cherry-pick explicit commits. Resolve schema, order, and authorization conflicts according to both business intents rather than accepting one side mechanically.

Review by responsibility

Area	Check
Config, overrides, MDX	Preserve your name, offers, provider mappings, and content
Auth and server APIs	Login behavior, authorization, Origin, limits, and variable names
Database and migrations	SQL, populated data, backward compatibility
Billing, credits, jobs	Signatures, ledger, idempotency, compensation, outbox
Components and styles	Current aliases, Base UI, and theme behavior
CLI and target-resources	Existing names/account and new planning behavior

The current UI update moves primitives to apps/web/src/components/ui while packages/ui retains helpers. Email-code sign-in is now the default; password login lives at /auth/password. Update help and tests alongside those commits instead of retaining stale imports or login instructions.

Preserve machine and production settings

Ignored .env, .dev.vars, and .muse state do not arrive through Git. Compare the new .env.example with existing variable names, adding required inputs without rotating production AUTH_SECRET. Review resource-name changes carefully so template defaults do not replace your database/bucket.

Install the committed lockfile with pnpm install --frozen-lockfile. Build first when generated modules are absent. Schema changes need reviewed migrations; do not generate unreviewed SQL directly during production deployment.

Validate and release

Run the relevant test layers, including the compiled Worker, and focus on changed authentication, payment, and task behavior. Review doctor and plan for unexpected resources or risky migrations before your release process.

Keep a code rollback reference and evaluate database recovery separately. After publication, inspect public smoke and real integrations. Record commit range, migrations, executed outcomes, and outstanding acceptance rather than copying old passing counts.