Updates And Upgrades

Treat your customized application as an owned fork: review upstream changes, identify conflicts at product boundaries, migrate deliberately, and prove customer journeys before release.

On this page

Classify every incoming change

ChangeReviewRelease action
Product behaviorCustomer workflows, copy, role access, and conflicts with your differentiating logic.Update acceptance tests, release notes, and customer communication.
SchemaMigration order, locks, RLS, grants, RPCs, indexes, generated types, and backward compatibility.Back up, apply in a rehearsal environment, regenerate types, and prepare forward repair.
ConfigurationNew, renamed, removed, or differently required variables and database settings.Update every environment and verify readiness before code depends on the value.
ProviderDashboard configuration, API version, webhook events, catalog identifiers, and capability changes.Use provider test mode and reconcile local projections.
OperationsJobs, schedules, alerts, logs, recovery steps, export limits, and data-retention behavior.Update runbooks and rehearse the changed operational path.
DependencyRuntime requirements, security advisory, lockfile, build output, and browser support.Run the full quality gate and representative production build.
  1. 1

    Create an upgrade branch

    Keep the production branch deployable. Record the source release or commit and your current production revision.

  2. 2

    Review before merging

    Read changelog and migration notes, then diff schema, env template, providers, auth, jobs, webhooks, shared UI, and every file your product customized.

  3. 3

    Resolve by ownership

    Preserve your product decisions intentionally. Do not accept incoming UI or domain behavior merely to make a conflict disappear.

  4. 4

    Migrate a rehearsal environment

    Use production-shaped data with redaction where required. Apply migrations, regenerate types, configure providers, and run repair or backfill steps.

  5. 5

    Prove the release

    Run quality and tests, then smoke-test auth, customer workflow, admin access, billing, email, webhooks, jobs, exports, and public content.

  6. 6

    Deploy with recovery ready

    Record deployment and schema revisions, observe queues and provider projections, and retain the compatible application rollback or forward-repair plan.

Do not call an upgrade complete until

  • The exact source and deployed revisions are recorded.
  • Schema, environment, provider, cron, webhook, and generated-artifact changes are accounted for.
  • Your customizations and intentionally removed modules still behave as designed.
  • Targeted tests, pnpm run quality, and the production build pass.
  • Rollback compatibility and database forward repair are understood.
  • Customer-visible changes, limitations, and manual actions are documented.