Firebase's real hold on a project is that clients talk to it directly: screens subscribe to database paths, read auth claims, call functions, and load files straight from Google's SDKs. A few tools here bundle several of those jobs at once - Kuzzle pairs authentication, data storage, search, and realtime messaging, and Directus wraps a SQL database in instant REST and GraphQL APIs with auth and an admin app - but none matches Firebase's full spread behind a single SDK, so the honest plan is still to map which services you actually depend on and replace them piece by piece. Authentication is usually the first and most self-contained piece to move, and SuperTokens targets exactly that - login, sessions, and multi-factor handling that run against your own database instead of a managed identity service.
The messaging and engagement side is a separate project. If your Firebase use leans on Cloud Messaging for onboarding, push, or re-engagement flows, Laudspeaker rebuilds that as a visual journey builder with segmentation across push, email, SMS, and webhooks. Auth and messaging still leave Firebase's database and hosting uncovered, but other tools here fill those in: Directus and Kuzzle stand in for the data layer, with Kuzzle adding realtime pub/sub, while Coolify and Kubero handle self-hosted deployment. Be realistic that a full exit usually means combining several of these rather than finding a single drop-in.
Plan the cutover around behavior, not exports. Auth records can often keep their user IDs, which matters when clients or URLs reference them, but password hashes may not be portable, so budget for a staged reset or a reauthentication flow that does not lock people out. Rewrite security rules as server-side authorization, run the old and new services side by side, and check read parity from your real mobile and web clients before you redirect any traffic.
