Open-source alternative to Cloud Functions for Firebase

Many teams keep Cloud Firestore or Firebase Authentication running while they move server code to a self-hosted platform. This is a reasonable interim state when the data layer is not yet ready to move, but it means the app now calls two backends. The new functions must verify Firebase ID tokens or be fed through a bridge that does, and the remaining Firebase services keep their own security rules, quotas and billing. Confirm which Firebase services stay, who owns each one, and how long the split is expected to last, since a long split doubles the places where access control must be correct.

• Token verification: Confirm that the new endpoints can validate Firebase ID tokens against Google's published keys before any sensitive operation runs.
• Dual access rules: Firestore security rules and the new function's authorization checks must agree, or users will see different data depending on the path.
• Split ownership: Record which team operates the Firebase project and which operates the self-hosted endpoints, along with on-call contacts for each.
• Duplicate writes: If a function writes to both systems during the transition, define which store is authoritative and how conflicts are resolved.
• Exit date: Set a written review date for the split so it does not become permanent by default.

Before cutover, check each new endpoint against the same test cases used for the Cloud Functions it replaces, including failure and retry behavior.

Moving the full backend means Firestore or Realtime Database data, Auth users, Storage files and functions all change platforms, usually in a planned window. Supabase documents migration paths from Firestore and Storage, and Appwrite offers a built-in Firebase migration, but both still require rewriting client SDK calls and checking that the data model survives the move. Because all services change together, client releases, DNS changes and data copies must be sequenced, and rollback depends on keeping the Firebase project readable until the new stack is verified.

• Client release timing: Ship the app build that calls the new endpoints before or with the backend switch, and plan for users on older builds.
• Read-only fallback: Keep the Firebase project intact and readable for a defined period so rollback does not require a re-export.
• Copy and delta: Plan a final incremental copy of data written during the migration window, since a single bulk copy will miss recent changes.
• Scope of the move: Confirm which Firebase features are not carried over, such as Realtime Database or Cloud Functions triggers, and decide how each is replaced.
• Verification: Test authentication, data access and file downloads with real accounts in the new environment before pointing production traffic at it.

The cutover checklist should name an owner for each service and a go or no-go decision point.

Cloud Functions often react to events such as a new Auth user or a Firestore write. When some Firebase services remain, those events still fire in Firebase, but the handler may now live on a self-hosted platform. Pushing events out requires an HTTP endpoint that Firebase can call, a shared secret or signature check, and retry handling that tolerates duplicate deliveries. Teams should also decide whether events are forwarded from Firebase or whether the self-hosted platform polls or subscribes to the data source directly, because each choice has different failure modes.

• Endpoint exposure: A webhook receiver must be reachable from Firebase, which means a public or allowlisted address with TLS in front of it.
• Signature checks: Validate a shared secret or signature on every inbound request and reject unsigned calls.
• Idempotency: Handle repeated deliveries by keying each handler on an event identifier so a retry does not send duplicate emails or double-count records.
• Ordering: Confirm whether out-of-order delivery can affect the handler's logic and whether the handler must read current state instead.
• Failure visibility: Log failed deliveries and alert on them, since a silently dropped trigger can look like a data bug weeks later.

Test each trigger by writing a known record and confirming that the self-hosted handler runs exactly once.

Cloud Functions requires the Blaze plan, the pay-as-you-go tier, so every invocation, build and outbound request is metered in the Firebase project. Running old and new functions side by side can therefore increase the bill during the transition, and the timing of when you stop deploying or invoking Cloud Functions determines how long that overlap costs. Confirm the current pricing for each Firebase product in the project from Google's documentation, since rates and free allowances change, and ask finance how the overlap will be budgeted and approved.

• Overlap cost: Estimate how long old and new functions will both run, and which Firebase charges continue during that period.
• Invocation drivers: Identify which triggers run most often, since high-frequency triggers dominate metered usage.
• Budget alerts: Set billing alerts on the Firebase project so unexpected spikes reach someone before the invoice does.
• Shutdown sequence: Disable triggers first, then remove deployments, so the bill drops as soon as the new path is verified.
• Quote inputs: When requesting a quote for the migration, specify the overlap period, the functions in scope and the Firebase services that remain, so the effort and recurring costs can be compared.

Confirm the final billing date with your Firebase account owner before scheduling the cutover.

Turning off Cloud Functions is the point of no return for server-side behavior, because deployments removed from Firebase cannot be restored from the console without redeployment. Before shutdown, confirm that every client call, trigger and scheduled job has an equivalent on the new platform and that nothing still depends on the old endpoints. Logs and metrics from the final period should be exported and retained according to your records policy, since the Firebase console will not be the place you look during an incident later.

• Inventory: List every function, trigger, scheduled job and HTTP endpoint, and mark the caller for each one.
• Traffic check: Review invocation logs over a representative period to confirm that no client or integration still calls an old endpoint.
• Parity tests: Run the same test cases against old and new handlers and compare outputs, including error responses.
• Log retention: Export logs and configuration needed for audit or investigation before deleting anything.
• Rollback path: Confirm who can redeploy the old functions and how long that takes if the new path fails.

Ask your security and compliance leads to sign off on the inventory and retention plan, and confirm each point against your own environment before disabling anything in production.