Sudarshan Dhakal wrote the path on 30 November 2025. Custom Node and Express first. Then Firebase, because auth and Firestore shipped a prototype in a weekend. Then Appwrite Cloud. Then a Docker install on his own VM.
He wanted Firebase speed without Google lock-in. He also wanted SQL-shaped data and a bill he could predict.
If you are looking at the same route, start with the Firebase → Appwrite playbook. Appwrite now has a Firebase migrator. Sudarshan’s post is the earlier, mostly hand-built version.
Why he left Firebase
Firestore reads got expensive when a client looped. Complex filters and full-text search pushed him toward extra services. An OR query was already a workaround.
Vendor lock-in sat under that. Pricing changes and deprecated features would land on Google’s schedule.
Appwrite Cloud was the first stop. Same “endpoint plus dashboard” feeling. When he wanted the data on a machine he ran, he installed the compose stack. Traefik, MariaDB, Redis, workers, ClamAV. He describes a $5 DigitalOcean droplet as a possible home. He does not publish the droplet size he used.
Auth was the hard part
He could not export password hashes from Firebase into Appwrite in a way that kept logins. Some projects got a gradual migration. Others got a hard reset.
The client code looked close. Firebase signInWithEmailAndPassword became Appwrite account.createEmailSession. That similarity is why the app rewrite felt smaller than the identity problem.
Appwrite’s current wizard asks for a Firebase service account with Identity Toolkit Viewer, which includes hash config. OAuth users still will not move, because those sessions live at the provider. Users sign in again. Sudarshan does not say he used that wizard. Plan for resets unless you have proved the hash import on a copy of production.
Database and files
He mapped Firestore collections to Appwrite Databases, then Collections, then Documents. Same tree, plus attributes for a schema.
That 1:1 map is the easy case. Appwrite’s docs say only top-level rows migrate in the official tool. Nested documents stay behind. Realtime Database is not a source. Functions do not come across.
Storage was a script. Download from Firebase Storage, upload to Appwrite buckets with the server SDK. He calls that straightforward. Compare a few PDFs and images after, because “uploaded” is not “opened.”
What I would copy
Move the app against empty Appwrite collections before the last Firebase export. The SDK change is the small part.
Decide the auth story in writing. Reset emails, or a lazy path that creates the Appwrite user on next login. Keep a Firebase uid column until every foreign key has been rewritten.
If you use the official migrator, read the limits first. Nested data, OAuth sessions, and functions are still your job.
The Firebase → Appwrite playbook covers Auth, Firestore, Storage, rules, and functions. Use Sudarshan’s post for the hash gap the similar SDK will not warn you about.