What does Appwrite handle for your app?
An Appwrite project can handle accounts and sign-in, saved records, uploaded files and code that runs on the server. Appwrite Cloud runs the service for you. If you install the open-source version on your own infrastructure, you handle the updates, storage and recovery.
For a first web app, connect your screens to the Appwrite project and choose how people sign in. Appwrite supports email and password and sign-in with external providers. You still build the screens and decide which records each user should see.
What belongs in the browser?
The browser needs the Appwrite endpoint, which is the address it calls, and the project ID. A signed-in user's session identifies them and lets Appwrite check their permissions. The address and project ID can go in the web app's configuration.
Keep API keys on the server for trusted jobs. A key with the right scope can access records beyond what an ordinary user is allowed to see. Use the normal user session to check private records, even if you used the Appwrite Console to create the sample data.
For password recovery on the web, build a reset page in your app and configure the allowed address. Appwrite can send a recovery link to that page.
How do you check that each user sees their own records?
Use a disposable copy of your app and a separate Appwrite test project. Before opening the app or creating accounts or records, match its configured endpoint and project ID to the test project. Check that sign-in, database and storage connections point only to that test project, including any connections in your app's server code. Disable messaging, functions and outside integrations unless they use separate test systems. If you cannot verify the connections, write out the checks on paper.
- Give each test account one noteIn the test project, create two test accounts using addresses you control. Make a TablesDB table with two fictional notes. Enable Row Security and give each account read and update access to only its own row. Leave table-wide read and update grants off. A table-wide grant can give access to every row even when you set row permissions.
- Try both ordinary sign-insUse separate browser profiles for the two test accounts. In the sample app, try opening and saving each note through test-only controls that use the signed-in user's session. The app should let you open and edit your own note and refuse both actions on the other note. Check that the other note stayed unchanged.
- Check the signed-out caseOpen a sample note in a browser profile with no session. It should stay private. If a check fails, inspect the table and row grants and check that the app used the intended session.
What costs change as the app grows?
Appwrite Cloud has a Free plan. On November 11, 2026, Appwrite listed Pro from US$25 per month. The plan applies to the organization. Check the plan’s active-user allowance, plus storage and bandwidth in gigabytes and serverless database reads and writes as operation counts.
Check the allowances before launch. Hitting a Free limit can stop parts of the app, and extra use on a paid plan can add charges. If you choose dedicated database compute, that compute is priced per database per month. If you self-host the open-source version, budget for the server, disks, backups and maintenance time.
What can you export or restore?
You can export a TablesDB table's rows to a CSV file on Cloud or self-hosted Appwrite. That file covers the selected table data. Plan separate recovery for accounts, uploaded files and settings.
Appwrite documents database backups and a restore to a new database for TablesDB on Cloud Pro and Enterprise. When self-hosting, back up the database, file volumes and configuration. For either setup, try restoring fictional records to a disposable destination and recheck both allowed and refused access.
Appwrite also documents moving selected accounts between its Cloud and self-hosted versions. Test sign-in and private record access with sample accounts after a move.